Do not re-compute window PoSt on revert

[Stebalien]

Currently, lotus will re-compute a window PoSt whenever it sees the chain revert back to the previous deadline. However, this isn't necessary as the window PoSt randomness is based on drand (which won't change).

Instead, we should:

1. Split the window PoSt process into two parts: proof generation, and message generation.
2. On revert, do not restart the proof generation.
3. If we revert past the ChainCommitEpoch, re-generate the window PoSt message with the new randomness, and re-submit it.

[dirkmc]

Proposed implementation:

• Split the window PoST process as suggested above:
  1. Proof generation
  2. Getting beacon randomness & Submitting message to chain
• Start Proving once we're at the deadline Challenge height (10 minutes before deadline Open)
• Start Beacon randomness + submit to chain once both
  • Proving is complete
  • We're at the deadline start height + confidence

Proposed states:

• Start
• Proving (proof generation)
• ProvingComplete (waiting for both proof and deadline Open + confidence)
• Submitting (getting beacon randomness & submitting message to chain)
• Complete

State changes would be triggered by changes in the chain height.

If the chain reverts to the previous deadline while we're in the Proving state, a state change would not be triggered. When the proof completes the scheduler would remain in ProvingComplete until the chain reached the required height.

If the chain proceeds past the deadline Close epoch, proving is aborted.

Note: Made some edits after talking to @magik6k