Make automatic storage deposits resistant against changing deposit prices

[athei]

The Vision

Currently, automatic storage deposits do not gracefully handle when the runtime changes the price per byte or per storage item: We just refund bytes_removed * current_price. One can easily see that for rising prices that can lead to the contract running dry of deposits (removing the incentive to cleanup) or on falling prices accumulating too much deposit that can only be removed by terminating the contract.

@shawntabrizi brought up a better way of doing this. Albeit making the whole process much more complex and introducing its own problems it makes the situation much better: The refunds are pro rata of the accumulated storage: If I remove 1% of storage I get back 1% of the deposit. This makes sure that the contract never runs dry and never has too much deposit.

However, there is a side effect of that. On falling prices this opens up arbitrage opportunities: Creating and removing storage in quick succession to gain deposit back cause creating storage is less expensive than the refund one gets for the same amount. At the end of the this is just someone bringing the deposit of a contract to the level where it should be after the prices were adjusted. We argue that this is OK.

On raising prices the refund will be less than what the depositor originally payed for it (given the arbitrage already took place). We argue this is OK because the depositor still has an incentive to gets its storage cleaned up even though the reward got smaller.

The Plan

We will just implement this in a single PR.

Open Questions

• Are the mentioned side effects a show stopper? We argue they are much better than what we have now.
• This will require a big storage migration where we count every contracts storage items. Do we need to go the extra mile and split this over multiple blocks? I don't think there is a production chain with enough usage to justify this.