Reduce storage deposit for parachain PVFs

[eskimor]

We would like to reduce the amount of locked token needed for PVF (Parachain Validation Function), but this comes with a number of challenges that need to be resolved first:

1. offchain XCMP: Merkle tree of para headers in beefy ignores Coretime chains #4737
2. (Re-)preparing artifacts for thousands of PVFs might take too much time, e.g. on executor parameter changes: Solution
   2.1. Migrate to PolkaVM (Instant preparation)
   2.2. Only enact executor paramater changes after valiators confirmed that they have the artifacts prepared with the new parameters prepared already.
3. Thousands of registered PVFs and flexible coretime would allow for the possibility of lot's of runtime upgrades to happen at the same time, causing DoS/reduced service to other parachains. See RFC-102 for a suggested solution.
4. HRMP message size/count limits should be reduced.
5. Anything else?

Further Improvements

Once we brought storage deposits down (with off-chain storage we also actually bring real costs down), we should also reduce the minimum fee for on-demand, given how low bulk cores are sold right now on Kusama.

[s0me0ne-unkn0wn]

Only enact executor paramater changes after valiators confirmed that they have the artifacts prepared with the new parameters prepared already.

A closely related discussion: #4791 (comment)

Indeed, if we have in-advance preparation and we already know executor params for the next session, we have a whole session worth of time to prepare the PVFs. Preparing a lot of them will still be slow, but given the session times on the production networks, it would probably suffice. Then we wouldn't need the separate logic for postponed executor params enactment.

[kianenigma]

1. What will happen today if all parachains switch to on-demand, and schedule themselves somewhat unpredictably? how hard is it for validators to prepare the wasms, offload, etc
2. What is the breakdown for the current deposit that's needed?

[burdges]

We've always wanted all artifacts built in advance, preferably an epoch in advance. Afaik we'll never change this goal, not even for polkavm, and #4791 improves this. We could simply rate limit code upgrades for 3 above, but polkadot-fellows/RFCs#102 includes some tunable cost for upgrades.

I'd think the deposit cost would represent the actual storage for artifact and bytecode. In principle, the deposit would partially cover build costs incurred by validator churn and executor params churn. I suppose governance eats the executor params churn costs morally, meaning some slowdown becomes acceptable. Also newly ellected validators spend the build time during their ellection, so again whatever.