dealbot funds draining

[SgtPooki]

dealbot uses DEALS_PER_SP_PER_HOUR (currently set to 4) and MIN_NUM_DATA_SETS (currently set to 15) to start creating data-storage checks and creating data-sets for SPs.

This causes a problem when new SPs join, and they may just be testing things, or may only be ephemeral, and causes dealbot to spin up a ton of data-sets with them before we're sure that they are going to stick around.

to get around this, we should:

1. keep the deny lists so we can exclude some SPs from testing entirely, and keep testing new SPs.
2. create an EXPECTED_APPROVED list of SPS that were listed as approved and that we do the 15 data-sets and 4 data storage checks per hour for.
3. any other SP (newly added, not blocked, or not expected_approved) gets maybe 1 data-storage check per 4 hours, and 1 data-set..

The EXPECTED_APPROVED list gives us a list of SPs that we know are already approved and expect to meet performance criteria, as well as a list of SPs that we are thinking about moving to approved.

cc @rjan90 @TippyFlitsUK

[TippyFlitsUK]

Suggested updated deny list entries for mainnet:

ruka-main - 9
pdp-superusey - 14
TSE REIERSEN - 29
TSE Reiersen -31
pdpnode01 - 33
StorageUsgp2 - 34
Bare Metal Cloud - 35

[SgtPooki]

I think that when blocking these SPs, we should also terminate the active rails associated with them.
- https://github.com/FilOzone/infra/pull/366#issuecomment-5290733652

100% @silent-cipher. can you put a runbook together for handling this? also, I think we need to get this issue resolved sooner than later so our wallet stops draining so much. I don't think we need to be pinging EVERY SP with 4 data storage checks every hour, and we certainly don't need 15 data-sets.

[silent-cipher]

#682 has been shipped to both prod and staging. The only remaining task is to create a runbook for terminating the active rails associated with blocked or SPs whose tiering changed from full to trickle.