XCM: Message Queues

[gavofyork]

Several improvements needed before we can lift the harsh restrictions placed on message queues at present:

• Introduce fees to allow actors on the Relay-chain to send DMP messages. XCM: Properly set the pricing for the DMP router polkadot#6843
• Ensure incoming DMP messages queue rather than execute immediately on receipt.
• Remove pallet::without_storage_info from all message-queue pallets (use Preimages pallet as needed).
• Relay-chain should limit per-block HRMP bandwidth to something manageable by not requiring all sending channels to move forward by a whole block at once.
• Ensure no queue overloads the PoV at message execution. This can be done fairly easily by only queuing messages whose size is less than some maximum. Messages which exceed the limit should be placed in the oversize message queue with the message data stored as a preimage. Both fields of the weight should be checked prior to execution.
• Allow suspension of any/all XCM queue processing for one block by an inherent if enough BABE slots have been missed.
• Limit reentrancy via a thread_local counter to limit stack depth which an Xcm Transact can create.

Once all items are complete, safeguards designed to avoid PoV-exhaustion can be removed. At this point, sane v2 -> v3 weight conversions must also be removed; instead the Weight should be approximately equivalent to a block's total PoV weight. This will make almost all v2 messages overweight on a v3 system. The practical fix is to upgrade to v3.

Related: paritytech/polkadot#6129

[xlc]

To confirm, we can remove the XCM SafeCallFilter once this PR is addressed?

[kianenigma]

To confirm, we can remove the XCM SafeCallFilter once this PR is addressed?

Yes, as per:

https://github.com/paritytech/polkadot/blob/7129e9bdba2c82e4b173f567b5d6a3c3f7191782/runtime/kusama/src/xcm_config.rs#L150-L157