Demand Response: Scheduling flexibility for expensive tasks

**Motivation**
Increasingly, _when_ you use energy is more important than _how much_ you use. See, for example, the [duck curve](https://www.caiso.com/Documents/FlexibleResourcesHelpRenewables_FastFacts.pdf) caused by solar production in CA. Shifting power use by several hours can affect whether the power you use is cheap and green or expensive and carbon intensive. Scheduling tasks in response to grid conditions (Demand Response, DR) has become a big topic in [data centers](https://www.researchgate.net/publication/259117661_Data_Center_Demand_Response_Avoiding_the_Coincident_Peak_via_Workload_Shifting_and_Local_Generation) in the past several years, and it would be awesome to build something like this into FC. Making this the default option could substantially help the power grid when FC gets adopted at scale, which would translate to significant environmental impact.

**Proposal**
Can we give miners some say in what time of day they do computationally intensive tasks, and make this easy for anyone in the network to participate in?

- It sounds like this might not be a problem for sealing. Can we allow storage miners to wait some number of hours before they seal a file?
- Alternatively we could make it easy for miners to submit bids during hours when they have inexpensive energy and seal immediately
- PoSt clearly doesn't give flexibility in how long you have to respond to a challenge, but could it give you some flexibility in determining when you are likely to be challenged (ie. twice as likely during some 6 hour period as during some other 6-hour period)?
- If you are challenged every day at the same time, can you do a one-time shift of that schedule?

There is no requirement here for the miner to determine exactly when they will have to do these tasks, just to have some statistical influence.

Start by reviewing the protocol sections covering sealing, storage-miner responses, and PoSt challenge timing. Determine whether the protocol can provide statistical control over task timing without violating response requirements. Done means a concrete, reviewed proposal defining the mechanism, constraints, and expected miner behavior.

Written by the indexing model from the issue text.