pay dispatch fee at target chain

[svyatonik]

closes #377
closes #561

Things to do in this PR (quite a lot - opening just to show some progress):

• actually return unspent weight from delivery call;
• test that transfer actually happens when using our messages adapter;
• update benchmarks - the worst delivery case is now when fee is paid at the target chain
• (most probably) weight of pay-dispatch-fee-at-target must not be paid by submitter when message is prepaid at source + we should refund relayer with this fee if message is already prepaid in delivery tx. This would require additional constant in chain primitives, which is a bit unfortunate.

Things to do in follow-up PRs:

• support pay-at-target-chain option in encode-call, send-message and other subcommands;
• actually generate pay-at-target-chain messages in test deployments.

[tomusdrw]

Nice!

[tomusdrw]

I was thinking a bit about burning part of that weight, or returning part of the fee to the message sender, but I concluded that it doesn't make much sense for now. Leaving the comment here for posterity though.

1. In case of target-chain fee payment, messages senders are heavily incentivised to specify the lowest possible weight, cause they pay up-front. Any unused weight is benefiting the relayers now by increasing their reward for accepting target-chain fee payment, which inherently increases the risk for them. So that seems to be quite aligned.
2. In case of source-chain fee payment, the situation is quite similar - in such case relayers risk is increased by price fluctuation though.
3. Hence message senders does not really benefit directly from having the dispatch consume less weight than declared, cause they pay for dispatch upfront. Burning part of the unused weight would only reduce reward for the relayers (which are exposed to a bunch of risks already) and would unnecessarily inflate block consumption.
4. Returning part of unused fee to senders reduces their incentive to calculate the fee correctly and increases risk for the relayers.

Overall we might consider doing a more detailed analysis, perhaps there is some fair split between returning/burning/leaving to the relayer, but taking into account real-world data will be a great help for this, so I'd rather collect it first :)
My gut feeling is that relayers are more on the upside here, but I think it's acceptable for the first deployment.

[svyatonik]

Some notes about weight of the delivery transaction - it has been increased from 1_000_000_000 to 1_500_000_000 (DEFAULT_MESSAGE_DELIVERY_TX_WEIGHT) in this PR. That's because of additional Currency::transfer call. This is the cost of worst-case single message delivery tx, where dispatch fee is paid at the target chain. However, the actual post-dispatch fee that the delivery call now returns is decreased by this additional cost (PAY_INBOUND_DISPATCH_FEE_WEIGHT) if fee has already been paid at the source chain.

As a result of ^^^, we now able to deliver only 704 instead of 1020 messages in single delivery tx. This may be 'fixed' by adding another parameter (something like number_of_pay_fee_calls) to the delivery tx, but it'll complicate a relayer code a bit (which is probably ok) + will add another pre-dispatch check in the call (which is also probably ok). The milestone of this fix actually depends on the expected use-case at real chains - if we'll have most/all messages that are paid at the target chain, then it's ok to leave as is for now + fix later. If we expect mixed/pay-at-the-source-chain usage, then it is better to fix before deployments.

[tomusdrw]

looks good to me! Couple of small grumbles and questions. I'm super sorry it took my so long to take a look at this.