Support multiple calls of `clear_prefix` with `limit`

[bkchr]

When calling clear_prefix with a limit multiple times in the same block it will always delete the same keys for the exact same input. The reason for this is that we don't check from the overlay on what we already have deleted. So, we always delete the same keys from the backend until the limit is reached. It was documented in #11182 to make this more clear to the FRAME users on how the internals are working.

@shawntabrizi and @kianenigma proposed that we make this more intuitive, aka calling it multiple times deletes always new keys and not always the same ones.

I'm personally not really convinced that we should do this, because:

• If you want to delete more items, you can just directly pass a higher limit or just call a second time with a higher limit.
• As the node side doesn't really know about the internals of the runtime, it would need to take into account the keys that are present in the overlay and make the implementation not count these towards the limit when we encounter them again in the backend. While this works, it also increases the complexity and may leads to a slower execution the more often clear_prefix is called.
• We would need to introduce a new host function version for clear_prefix where only version 3 is using the new implementation. This needs to be done to ensure that we don't break any old blocks.

[shawntabrizi]

If you want to delete more items, you can just directly pass a higher limit or just call a second time with a higher limit.

We can't assume how the code is written, and that multiple calls can be collected together. Imagine two separate triggers of this call happen from two different places, where both of the triggers are correct and accurate.

[bkchr]

That sounds already like some bug? The idea why you use clear_prefix with some limit is that you don't read too much in one block and instead do it over multiple blocks. If something tries to trigger an operation that should run over multiple blocks, is triggered twice per block sounds like a bug to me.

[gavofyork]

That's one possibility, but it's not the only one. It's perfectly reasonable that a transactor calling a storage cleanup operation does so without using the entire (or even half of) the block's weight. One reason would be because they might not want to take the risk of the block having that amount of weight free. But regardless it should be supported. And if two of these transactions happen to be bundled in the same block then we'll end up with a broken state change.

Imagine a pallet which pays people a small amount to do storage cleanup. Unless it happened to be engineered to strictly limit one cleanup operation per block (and I don't see why it would) then it's trivially attackable.