Expose CLI for explicit chain sync and head manipulation

[anorth]

Description

While debugging staging-0.5.0 I added some debug statements to the storage miner actor code. The only way to trigger these was to destroy my repo and then re-sync the chain, including re-fetching it from remote peers. Now that a new release has been deployed, I can't do that.

It would be more efficient and direct to instead support explicit rewinding of chain head back to the genesis, and then sync of the desired head tipset. This would cause the chain to be re-validated (fetching all the required data from the local store).

Chain import export #3443 could be another solution to the general problem.

Acceptance criteria

• chain set-head <cid>.... command replaces the chain store's head with the provided tipset key cids (which must be present in the store)
• chain sync <cid>... invokes HandleNewTipset with the provided tipset key, revalidating that part of the chain subsequent to wherever the new head diverges from the prior chain.

Risks + pitfalls

These commands allow an unwitting user to screw up their local chain state. I don't think this should be a dominating concern during the present stage of development.

FYI @ZenGround0 @frrist

[frrist]

The syncer uses the store's HasTipSetAndState method as a stopping point, it's the first call HandleNewTipSet makes, and is also used in the fetcher callback. Would we expect the set-head command to erase all state from the chain store's TipsIndex that is a child of the head state we are setting?

As the code read now, the syncer will not resync any head it already has state for.

[frrist]

These commands allow an unwitting user to screw up their local chain state. I don't think this should be a dominating concern during the present stage of development.

Given this I would feel comfortable with either (A) adding an option to the syncer that instructs it to ignore previous state while syncing or (B) Diffing the current state with the state of the head we are setting, and removing it from the TipIndex's state map when calling SetHead or (C) bouncing the node after a call to SetHead to trigger chain reprocessing.

[anorth]

For a first pass, (c) bouncing the node is ok. But otherwise yes I think we should expect something like (b) to remove all entries from the in-memory tip index that are not on the chain defined by the new head.

We could use this to make it safer too. A rewind rather than set-head could require that the provided tipset actually be on the chain from genesis (inclusive) to head, and the implementation could then walk back up the chain, dropping the in-memory state as it goes.

[ZenGround0]

This mostly LGTM. The general idea is great. If we were designing a CLI that Did the Right Thing, then set-head would not do something drastically different from the internal set head (clear the internal tipindex). Instead it would just reset the head pointed to by the chain store. Then a separate command i.e. trim would remove all chain state not on the longest chain. The code for trim in this proposal would be somewhat related to #2634 but expanded in scope to garbage collect tipsets in memory too.

The above ideas might take more time to work out so I understand if throwing all functionality on set-head is the right choice to make now for quick turnaround of setting up debugging tools.

[frrist]

closed via #3444