ChainSync: let GSM disable and re-enable CSJ; also enable LoP in PreSyncing

[nfrisby]

Fixes #1490. Also a couple minor related changes:

• Enables the LoP in PreSyncing instead of just Syncing (minor).
• The GSM now notifies other components of its transition instead of just the final state. This is useful because the PreSyncing state can be transitioned to from either Syncing or CaughtUp, and the appropriate reaction may depend on which.

[nfrisby]

This is Draft because:

• No tests (see Issue Enriched Genesis tests to confirm all Genesis components are disabled when GSM transitions to CaughtUp #1491).
• I'm not yet sure the CSJ re-enable logic I've added here is respecting the CSJ logic's invariants.

[nfrisby]

Considering the context of this PR, it seems worthwhile to double-check this claim now, even though Issue #1491 will to.

[nfrisby]

TODO Now that the CSJ changes are actually so minor, we should split out the LoP changes. It'll make backporting the CSJ diff that much easier.

[nfrisby]

The only motivator I can think of for trying to handle this transition more carefully is if there's a bug in the CaughtUp BlockFetch such that the node might have several honest peers that are stuck on the forecast horizon "arbitrarily far" behind the wall clock (the hypothetical bug would be that the node has honest peers but is for some reason failing to download their blocks for more than ~20 minutes). If the GSM CaughtUpPreSyncing transition ultimately unstucks the node, then its selection will finally advance, and now all of those honest peers will have to send all the headers between where the node had been stuck and the actual wall clock. Note that the node might have been stuck for much more than 20 minutes (ie for multiple cycles of the GSM anti-thrashing delay).

But it seems unwise to complicate CSJ to guard against a potential bug in CaughtUp's BlockFetch logic. IE we should assume that a node whose selection is far behind the honest chain simply has been eclipsed: ie has no honest peers, and so CSJ isn't obligated to reduce load on whatever upstream peers the node had during the eclipse.

[nfrisby]

What do you think, @coot @crocodile-dentist ? We can chat about it on the 7th, if you'd rather.