feat: xcm taxing

[sander2]

This is a proof of concept of taxing xcm transfers. It is not feature complete - see the todo list below for info on what is still left to be done. Although tests are failing, I have verified that taxing from and to the relay chain works.

This implements a wrapper around the the ExecuteXcm trait implementation, that modifies processed XCM messages prior to execution (inbound or outbound) such that 10% of all tokens being transferred are sent to the treasury. Again, this only serves as a proof of concept - as listed below, things like configurable taxing rates are still to be implemented.

Left to do before we can consider merging this:

• make taxing rate configurable. The easiest would be to use the same rate for all tokens, inbound or outbound, regardless of whether those tokens are native to our chain. But if we want settings per direction and/or token we can implement that as well.
  • decide on requirements
  • implement it
• Transfer taxes to the reward pools rather than to the treasury account
• Decide what to do with non-native currencies - current reward/staking logic only works for our native tokens
• Possibly exempt governance/treasury transfers from taxes?
• Possibly write a script to inspect all past xcm messages to see if any would have failed with the new logic
• General cleanup
  • Moving code to its own pallet
• Add test cases
  • Outbound transfers:
    • Transfer to reserve
    • Transfer our own tokens to non-reserve
    • Transfer external tokens to reserve
  • Inbound transfer: from reserve
  • Test that non-token transfers still work (e.g. HRMP opening)

Note: current logic still takes the normal fee for execution (a set fee per instruction) in addition to the tax.

It's also important to note that while most messages will continue to work as before, it is possible to construct messages that will fail with this new executor. The DepositAsset, DepositReserveAsset, InitiateReserveWithdraw typically use filters that transfers the entire holding content to the target, but in theory it is also possible to have them send a set amount instead of All. Such instructions could fail if the holding register contains less than expected due to the tax. Another instruction that can fail is Transact - if the extrinsic requires a specific balance.

[nud3l]

* [ ]  make taxing rate configurable. The easiest would be to use the same rate for all tokens, inbound or outbound, regardless of whether those tokens are native to our chain. But if we want settings per direction and/or token we can implement that as well.
  
  * [ ]  decide on requirements
  * [ ]  implement it

It's a bit of a tricky question, but I think we only want to tax kBTC/iBTC. Even when iBTC/kBTC are provided to lending or LPd in the DEX, they are but to use on the Interlay/Kintsugi networks so I don't see a reason to impose extra tax on them.

* [ ]  Transfer taxes to the reward pools rather than to the treasury account

Transfer to treasury is good. Vaults mostly care about the block rewards.

* [ ]  Decide what to do with non-native currencies - current reward/staking logic only works for our native tokens

Native tokens only is sufficient.

* [ ]  Possibly exempt governance/treasury transfers from taxes?

For simplicity, I think we should tax everyone the same.

* [ ]  Possibly write a script to inspect all past xcm messages to see if any would have failed with the new logic

Might be nice to do that. Most effort will be to get all partners to update the fee estimation in their UIs/wallets.