Integrate token swap pallet into Millau runtime

[svyatonik]

on top of #1087

This still needs to be tested (=> another relay-related PR), so it'll be in draft state for some time. Opening it to not to lose this work somewhere among my local 363 branches.

[tomusdrw]

Can you elaborate on why the fee is now being declared by the user? What happens if too low value is declared (I'm assuming the message lane pallet should reject that, right?)
Is there so much variation in the possible fees or is it there to make sure users can pay an extra "tip"?

[svyatonik]

TBH I was not thinking about extra "tip" - it's just the inconsistency I've met between ability to specify message dispatch weight (#944 (comment)) and the fact that message fee is now 'hardcoded' in token-swap pallet (

parity-bridges-common/modules/token-swap/src/lib.rs

Line 118 in 9eaae41

type MessageDeliveryAndDispatchFee: Get<<Self::ThisCurrency as Currency<Self::AccountId>>::Balance>;

). So I've made signature of this method to look like usual send_message call of the messages pallet, where use can specify both message weight and fee. Could remove it and change MessageDeliveryAndDispatchFee() -> Balance to something like MessageDeliveryAndDispatchFee(DispatchWeight, Size) -> Balance if you think it's better.

[tomusdrw]

My initial idea was for the token swap pallet to be "simpler to use", i.e. not requiring sophisticated UI logic to estimate the costs, but rather have the pallet do that for you. That said, I'm fine to start with this API and let's see how it evolves.

[svyatonik]

OK, let's replace it with MessageDeliveryAndDispatchFee(DispatchWeight, Size) -> Balance

[svyatonik]

On second thought I think it is better to keep this as an external argument. I've recently seen an issue (#1138) where actual conversion rate has been larger than the rate that is stored within the runtime. So I'm proposing (apart from fixing pauses described in #1138) to add RPC call that estimates 'rational' message delivery and dispatch fee - e.g. you'll call it with custom conversion rate (which you may compute from offchain data) and it'll use max(external_conversion_rate, stored_conversion_rate). If we'll remove this argument, then some messages may stuck (because we'll fail to update rate on time). We have a solution for stuck messages (increase_message_fee or altruistic relayers), but better not to use it.