[Runtime] Bound XCMP queue

[ggwpez]

Re-applying #2302 after increasing the MaxPageSize.

Remove without_storage_info from the XCMP queue pallet. Part of #323

Changes:

• Limit the number of messages and signals a HRMP channel can have at most.
• Limit the number of HRML channels.

A No-OP migration is put in place to ensure that all BoundedVecs still decode and not truncate after upgrade. The storage version is thereby bumped to 5 to have our tooling remind us to deploy that migration.

Integration

If you see this error in your try-runtime-cli:

Max message size for channel is too large. This means that the V5 migration can be front-run and an
attacker could place a large message just right before the migration to make other messages un-decodable.
Please either increase `MaxPageSize` or decrease the `max_message_size` for this channel. Channel max:
102400, MaxPageSize: 65535

Then increase the MaxPageSize of the cumulus_pallet_xcmp_queue to something like this:

type MaxPageSize = ConstU32<{ 103 * 1024 }>;

There is currently no easy way for on-chain governance to adjust the HRMP max message size of all channels, but it could be done: #3145.

[muharem]

I wonder if MaxPageSize affects the weights a lot. From what I can read below, only one signal for every para id. The size can be constant, if it really make any difference.
I assume we could even use a Signal type here, but that would require a migration.

[ggwpez]

Yea true. In the past, there was the possibility for multiple signals to be enqueued, but i removed that, since later signals completely overwrite any previous ones.
Now indeed it is wasting weight here... it could probably be changed to something very small, like 16 without an issue. But it could also require a migration, so with the Weak vector and large size we at least are at no risk.