new DataSet creation on regular intervals for each SP

[silent-cipher]

Right now, a DataSet is created only once for each unique combination of metadata and Storage Provider (SP). This makes it hard to detect issues that users face when creating a DataSet with an SP even if uploads to that SP are working fine.

In practice, we’ve seen cases where:

• Piece uploads succeed with an SP, but
• Users fail to create a DataSet with the same SP, blocking them from uploading data at all.

To improve test coverage and catch these situations earlier, we want an environment-controlled mechanism to create new DataSets regularly.

Task

• Introduce an environment variable that configures the frequency at which new DataSets should be created per SP.
• Implement logic to create a fresh DataSet for each SP on every cycle/interval.
• Ensure the new DataSet replaces the previous one for testing purposes without causing race conditions or conflicts.

Notes

• May require a future issue to clean up old or unused DataSets to save wallet funds.

[SgtPooki]

related to #284

[rvagg]

This is good to exercise but we have to be aware of economics for SPs and make sure that dealbot ends up spending more on storage than it costs an SP to manage dealbot data sets. So factors to consider here:

• SPs pay all the gas fees for on-chain operations (FIL, not USDFC), this isn't passed on directly to the client, it's meant to be recuperated over time in storage fees
  • nextProvingPeriod, provePossession daily for a data set, addPieces and scheduleDeletions are semi-regular operations that also attract gas costs
• It costs an SP 0.1 FIL (not USDFC) to create a new data set, this isn't directly recuperated from the user, it's meant to be recuperated over time for storage fees for that data set
• Floor price of 0.06 USDFC/month (not FIL) per data set is designed to offset gas and fees over time, but it only applies to data sets that have pieces in them (one reason we might remove CreateDataSet entirely, or at least disable it in Curio, so CreateDataSetAndAddPieces is the only path)
• There is a 30 day lock-up that exists to ensure SPs get paid for storage even when the client is in default, but we've also made it possible to delete pieces at any time (there is a delay for deletion to take effect, up to 1 proving period). So a client can make a data set, delete pieces, and the SP doesn't get paid enough for it to be worth the bother.

So it's possible for dealbot to put costly churn onto SPs. If a normal client did this, they might block them, but they can't block dealbot if they want to participate in FOC, so we should make sure that money that goes in to dealbot, flows to SPs such that it's not a financial drain on them. Creating new data sets should be paid off by maintaining them over time. We could even do careful calculation of how much it cost an SP to run a data set, but it might just be easier to have a heuristic that gets applied to any churn in the system to ensure total funds flowing to an SP doesn't undershoot total cost for an SP to maintain this.