Gateway should no longer build token registration XCM

[vgeddes]

Instead, I've modified the protocol so that:

1. Users can still pass raw xcm blobs
2. The gateway itself can pass a "template id" like CreateAssetXCM of raw xcm.

Then the inbound-queue on BH can either passthrough the raw xcm or build the create asset XCM.

[vgeddes]

@alistair-singh @claravanstaden @yrong to give more context, this change opens up the possibility of users not strictly needing to pass raw XCM through the bridge to Polkadot.

Instead they can pass in a simpler ABI-encoded data, like:

struct Transfer {
  destination: Location,
  destination_fee: DestinationFee,
  beneficiary: Location,
  transact: Option<Bytes>,
}

// How to obtain destination fee on AH
enum DestinationFee {
    // Swap native ether in `message.value`
    SwapEther {
        in: amount
        out: (Location, amount)
    },
    // Swap asset in `message.assets`
    SwapAsset {
        in: (u8, amount)
        out: (Location, amount)
    },
    // Directly use some amount of an asset in `message.assets`.
    Asset: (u8, amount),
}

Then the inbound-queue can build an XCM that does the following:

• Obtain the destination fee according to the DestinationFee instruction on AH
• Adds an InitiateTransfer instruction that forwards message.assets to destination
  • Sets the asset claimer on the destination to beneficiary
  • Deposits into beneficiary account
  • Optionally executes an XCM::Transact

This would simplify the UX and also make it easier for to on-chain contracts to send messages to Polkadot without having to build XCM. It is hard to build XCM onchain.

Would this be useful?

[yrong]

IMHO, it will introduce additional complexity to the on-chain logic. I still prefer the raw XCM version, which offloads the complexity to off-chain.