Add AllowTransferAndSwap Filter for pallet_xcm

[apopiak]

As parachains we want to allow sending of XCMs that combine various transfer and swap instructions. The most flexible way of doing this is allowing pallet_xcm::execute for some subset of instructions. We have thus written an XcmExecuteFilter that allows some instructions (ClearOrigin | SetFeesMode | BuyExecution | ExchangeAsset | WithdrawAsset | TransferAsset | DepositAsset | ExpectAsset | InitiateReserveWithdraw | DepositReserveAsset | TransferReserveAsset) we consider necessary for the functionality but hard to exploit.
The filter further limits the amount of instructions and the maximum recursion depth to allow for deterministic weight of the filter itself.

We hope to establish this filter as a default so UIs can send XCMs to pallet_xcm for any parachain (that uses pallet_xcm and this filter).

Developed with @dmoka and @jak-pan for HydraDX.
We've been running the filter in production on Basilisk for a while.
See here for the original PR.

[bkontur]

cc @KiChjang @franciscoaguirre

[KiChjang]

First question: why is this implemented as a call filter rather than a barrier?

[apopiak]

Sorry for the slow reply!

This is implemented as a call filter because we want to modify the filtering behavior of pallet_xcm, not the executor. The executor will execute these kinds of instructions just fine (or not, if the barrier is very strict).
By default pallet_xcm::execute is locked down tight in the ecosystem, tighter than the underlying barriers for the executor.

[bkchr]

CC @franciscoaguirre @acatangiu

[acatangiu]

@apopiak on Relay and System chains we've completely opened up the filters: polkadot-fellows/runtimes#285, polkadot-fellows/runtimes#261, polkadot-fellows/runtimes#345

So, the recommendation is for other parachains to do the same (assuming they're using recentish versions of the SDK that include mature, battle-tested XCM code and configs).

It's also obviously ok for parachains to configure more restrictive custom filters, but these would be parachain specific.

In this context, is the PR still relevant? Any reason I'm missing, that you'd want this custom filter to be part of the SDK, rather than runtime-specific?

[jak-pan]

@apopiak on Relay and System chains we've completely opened up the filters: polkadot-fellows/runtimes#285, polkadot-fellows/runtimes#261, polkadot-fellows/runtimes#345

So, the recommendation is for other parachains to do the same (assuming they're using recentish versions of the SDK that include mature, battle-tested XCM code and configs).

It's also obviously ok for parachains to configure more restrictive custom filters, but these would be parachain specific.

In this context, is the PR still relevant? Any reason I'm missing, that you'd want this custom filter to be part of the SDK, rather than runtime-specific?

I think this PR is not relevant anymore given the facts stated above