Retry deals with start epoch in the future, if the sectors they've been added to initially fail to seal

[nonsense]

Checklist

• This is not a new feature or an enhancement to the Filecoin protocol. If it is, please open an FIP issue.
• This is not a new feature request. If it is, please file a feature request instead.
• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
• I have a specific, actionable, and well motivated improvement to propose.

Lotus component

• lotus daemon - chain sync
• lotus miner - mining and block production
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt)
• lotus miner/market - storage deal
• lotus miner/market - retrieval deal
• lotus miner/market - data transfer
• lotus client
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Improvement Suggestion

Currently in Lotus, after we add a deal to a sector, we remove it from the markets staging area, and pass it to the sealing subsystem which adds a piece to a sector, and then attempts to seal a sector.

However if a sector fails to seal for some reason, even if some deals are still good in it, there is currently no retry mechanism to try to add them to another sector and seal a new sector with the good deals.

We should figure out how to improve this, some ideas:

• there should be a mechanism for sector FSM to tell the deal FSM that a sector got removed
• each deal should check itself and if it is still good, it should be added to a new sector
• we should figure out how to extract a deal from a failed sector, and re-add it to a new sector, given that it is no longer available in the markets staging area.

[ZenGround0]

This should also be done for snap deals upgrades

[ZenGround0]

While looking into this for snap deals upgrades one particular problem I ran into is that the FSM loses track of which data goes with a deal once that data has been added as a piece into a sector. The cleanest solution is to give control of the deal back to the Deal FSM which can then give control back to the Sealing FSM if checks pass. The minimal thing we need from the Deal FSM is a way to get data from a deal id.

If we can't change the deal FSM like this we can resort to extending some internal sealing FSM interfaces to allow for internal unsealing. This is less general since it won't be able to handle incorrectly sealed sectors for example.

[jennijuju]

This will be highly desirable for the May Sprint.