Pre-support logical HRMP channels in pallet-xcm-bridge-hub-router

[svyatonik]

part of #2391 that may be implemented in our repo

This PR should add:

• the per-bridge delivery fee factor - now all bridges using the same pallet-xcm-bridge-hub-router instance are sharing the same fee factor. Logical HRMP channels should solve that, so it'd be better to have different fee factors for different bridges;
• outbound messages queue to the pallet-xcm-bridge-hub-router, where messages are saved when the bridge is suspended;
• code to serve outbound messages queue from on_idle when the bridge is resumed;
• cleanup

Opening it early for visibility + maybe someone would propose better solution for problems that I've met (will leave comments).

[svyatonik]

Now we have multiple delivery fee factors - one per every bridge. So the most straightforward solution to decrease this fee factor from on_initialize is to loop over all bridges in every block on_initialize and decrease it. However it seems too dumb. Especially, given that is_congested call will return the same value for all bridges.

So what I'm currently thinking of is to have two fee factors. The first one will be shared by all bridges and will be decreased from on_initialize only when the channel with bridge hub is uncongested - let's call it CongestionFeeFactor. The other one will be per-bridge. We'll be decreasing it when a message is sent over the bridge. It'll be the BridgeFeeFactor.

So the total fee would be the (base_fee + msg_len * byte_fee) * (CongestionFeeFactor + BridgeFeeFactor - 1).

[svyatonik]

I've removed this configuration - now the pallet has the separate Bridges storage map for that. Also - BaseFee is returned because of that. It solves the #2380

[svyatonik]

In other words, "opening the bridge" would now mean: (1) inserting an entry to the storage map (2) calling the open_bridge method of pallet-xcm-bridge-hub at sibling/child bridge hub. Right now it needs to be done using governance, but we may add some helper functions for that later

[svyatonik]

If the bridge is suspended (because some of its channels are congested), we have 2 options here imo:

1. save messages here and send them later, when bridge operations are resumed - that's what I'm trying to implement here;
2. (the easiest one) simply return an error. Then the sender will get a corresponding error and his transaction will fail. So tokens are not lost (given that the "delivery" is called by actual sender - if it's just a call somewhere in the middle of the path, it'll be lost)

WDYT is better?

[acatangiu]

hmm.. the first option makes using this pallet easier - no need to verify all paths leading to this pallet and whether messages/tokens can be lost, and the implementation here doesn't add much complexity so I say we stay with 1.

We'll ultimately see in audit 🙈 😆

[svyatonik]

There are some concerns with option 1 (I'll add a couple of comments during cleanup), but I agree that it is easier to use :)

[svyatonik]

I've seen how it is computed in other senders (blake2_256), but haven't seen how it is actually used. Shall we care about this value at all?

[svyatonik]

TLDR: SendXcm has two methods - validate that converts xcm message and destination into Ticket. And deliver, which accepts ticket. Normally deliver is called right after validate and Ticket is not designed to be encoded and stored anywhere. We need to suspend delvier call until bridge is resumed, so we need to save ticket.

Instead of saving ticket we may e.g. save (xcm, destination) and recall validate when bridge is resumed after suspension. Don't know what is better