XCM: Allow reclaim of assets dropped from holding

[gavofyork]

Introduces a mechanism for systematically allowing the rescue of lost contents of the Holding Register.

Fixes #3694

Trapping assets

XCM Executor's config now includes AssetTrap type which is a hook to which the contents of the Holding Register is passed at the close of execution. Like OnResponse, a (recommended) implementation is provided by the XCM pallet.

This will record a hash of the assets left in the Holding Register at the finish of execution together with the origin. A later claim may be made from the origin in order to resurrect the assets. This is done through the single-function trait ClaimAssets which verifies that the assets to be claimed match a hash placed by the same origin.

If the version with which the MultiAssets have been stored is not the most recent version, then the version index must be included within the claim ticket parameter, a MultiLocation as a GeneralIndex.

ClaimAsset

A new instruction is provided, ClaimAsset, which gains access to any ClaimAssets implementations exposed to the XCM Executor. If the pallet_xcm::Pallet implementation is exposed and the origin has unclaimed assets trapped, then those assets may be provided (exactly, as a hash of them is used to validate the claim) together with a ticket reflecting the version of XCM at the time of the trap (or Here if unchanged) and they will be resurrected into the Holding Register.

Additional

Also introduces the Trap instruction and error type to force an error to be thrown, and be able to recognise it. It comes with a u64 parameter to allow some degree of information to be conveyed with it (without bloating the stack footprint of XcmError).

Migration

xcm_executor::Config

Two new type definitions are required, and they'll generally want to point at the XCM Pallet concrete type if there is one, e.g.:

impl xcm_executor::Config for ExecuteXcm {
	/* snip */
	type AssetTrap = XcmPallet;
	type AssetClaims = XcmPallet;
}

Note that destinations which use v1 or v0 for message transport will not be able to use these features (even if the destination supports v2).

TODO

• ShouldTrap filter type to allow runtimes to dictate which assets/origins should be trapped.
• Unit test.

[KiChjang]

Do you mean "claim" instead of "create" here?

[gavofyork]

In this context they're interchangeable - the Assets will be "created" in the sense that the MultiAsset instance(s) will be created.

[KiChjang]

Nothing really stands out as concerning, aside from some minor documentation stuff.