Dynamic fees v1: report congestion status to sending chain

[svyatonik]

closes #2315

TODO:

• required changes to the pallet-xcm-bridge-hub-router at the sending chain: ac799a8
• required changes at the bridge hub: d78f106 and c364846;
• integrate into Cumulus and do manual tests: https://github.com/paritytech/cumulus/tree/sv-bridges-and-new-message-queue;
• unit tests;
• cleanup.

What this PR does:

1. instead of physically suspending the XCM channel Source.AH -> Source.BH, we are sending the "congested" message from Source.BH to Source.AH when the lane has more than OUTBOUND_LANE_CONGESTED_THRESHOLD messages;
2. upon receiving this message, the Source.AH starts increasing fee for every bridge message;
3. once oubound lane has more than OUTBOUND_LANE_UNCONGESTED_THRESHOLD messages, it sends the "uncongested" message to the Source.AH;
4. upon receiving this message, the Source.AH starts relieving the fee factor.

Obviously there's a period when the "congested" message is sent to the Source.AH, but is not yet dispatched. So messages may be sent with a constant (previous) fee. This may be alleviated by e.g. sending a ping message when OUTBOUND_LANE_CONGESTED_THRESHOLD messages are sent and if pong is not received in N blocks, start increasing the fee. This is what has been done in the #2233 initially. IDK if we need to do that, because:

1. the HRMP cost (which is a part of fee) still has its own exponential fee, which would make messages more expensive;
2. I've added another condition to start increasing the exponential fee - if inbound HRMP queue from Source.BH to Source.AH is suspended (meaning that Source.AH is failing to process inbound messages in a timely manner), then we trigger our own exponential fee increase mechanism.

So to me it looks like the above is enough for us, because it'll be expensive to fill up both queues (Source.AH -> Source.BH and Source.BH -> Source.AH). Also it needs to be coordinated carefully, so that the Source.BH -> Source.AH won't trigger the channel suspension. But please share your thoughts

UPD: in other words, with current implementation, we accept the fact that if the Source.BH -> Source.AH XCM channel is NOT congested, bridge messages may be sent with constant bridge fee (although HRMP fee may apply its own exponential factor meanwhile) while "congested" message is being delivered. We may also change the is_congested impl a bit and look at the number of unprocessed Source.BH -> Source AH messages and if it is larger than some N, consider it congested. The N may be for example the average number of messages, processed at a single Source.AH block.

[svyatonik]

Relevant commit: paritytech/cumulus@c0e3225. I'll remove this TODO before merging

[bkontur]

@svyatonik
just nit, in your Cumulus branch, I have never seen CumulusXcm used anywhere, I guess this module is really not needed and maybe will be removed,
and for matching XCM origin (e.g. from sibling parachain for example for ForeignCreatetors) we used something like this:

                let origin_location = EnsureXcm::<Everything>::try_origin(origin.clone())?;
		if origin_location.eq(BridgeHubKusama::get()) {
  ....
                }

[svyatonik]

CumulusXcm

@bkontur Which code exactly are you talking about? Could you, please, share a link?

[bkontur]

CumulusXcm

@bkontur Which code exactly are you talking about? Could you, please, share a link?

paritytech/cumulus@bridge-hub-kusama-polkadot...sv-bridges-and-new-message-queue#diff-9a51956f7781a349d207a9d5f54ea0061666a856fb108d1a1190bd5178eaac50R647-R657

hmm, I am sure that I saw there CumulusXcm somewhere :D :D , nevermind :D

[serban300]

Looks good. Just left a few small comments

[bkontur]

maybe also to trigger some event here, I know that inner send_xcm creates one,
but maybe could be useful for later analyse if something happens - https://github.com/paritytech/parity-bridges-common/issues/2323

[bkontur]

lgmt