Make AssetId and MultiLocation non-Copy; make Instruction 92% smaller

[koute]

This PR makes the following changes:

1. AssetId, MultiLocation, Junctions are not Copy anymore and need to be explicitly clone()'d.

2. The sizes of XCM types are now drastically reduced.

   Before:

   v2::Instruction - 1208 bytes
   v3::Instruction - 1472 bytes
   v2::MultiAsset - 624 bytes
   v3::MultiAsset - 752 bytes
   v2::MultiLocation - 584 bytes
   v3::MultiLocation - 712 bytes
   v2::AssetId - 584 bytes
   v3::AssetId - 712 bytes
   v2::Junctions - 576 bytes
   v3::Junctions - 704 bytes
   

   After:

   v2::Instruction - 96 bytes
   v3::Instruction - 112 bytes
   v2::MultiAsset - 72 bytes
   v3::MultiAsset - 80 bytes
   v2::MultiLocation - 24 bytes
   v3::MultiLocation - 24 bytes
   v2::AssetId - 32 bytes
   v3::AssetId - 40 bytes
   v2::Junctions - 16 bytes
   v3::Junctions - 16 bytes
   

3. The Junctions type is now internally boxed, or more specifically Arc'd, and acts in a copy-on-write fashion. This makes it cheaper to clone (now it only has to bump the refcount instead of copying over half a kilobyte).

4. The canonical way of constructing a Junctions is now through a conversion from an array.

   Before: let xs = Junctions::X2(OnlyChild, OnlyChild)
   After: let xs: Junctions = [OnlyChild, OnlyChild].into()

5. Since Rust doesn't (yet) support pattern matching of boxed values this makes it not possible to directly match on them, however this can be worked around by converting the internal Junctions into a slice and matching on that, for example:

   Before:

   match location {
        MultiLocation { parents: 1, interior: X1(AccountId32 { id, .. }) } => { ... }
   }
   

   After:

   match location.unpack() {
       (1, [AccountId32 { id, .. }]) => { ... }
   }
   

6. A few of some of the previously const functions and statics were made not-const since an Arc cannot be constructed in a const context.

Potential open questions

1. Do we want to make the Junctions type completely opaque? There might not be much of a point in keeping it as an enum now, since you can't directly match on it anyway. (Although this could potentially change in the future when Rust will support matching of boxed values.)
2. Do we want to keep Junctions::unpack returning a tuple, or perhaps introduce a JunctionsRef type so that the parameters are named when matching?

---

(This still needs a Cumulus companion, which I will add once paritytech/substrate#14158 is merged.)

[gilescope]

would be nice if arg order was switched: junctions, range so it's the same as JunctionsRefIterator above

[koute]

This is deliberate. The arg order must be like this because self is moved into JunctionsIterator, and once you move it you can't call self.len().

[gilescope]

On the whole I really like this.

[gavofyork]

I'd prefer to keep the declarative syntax. As a rule, top-level runtime files should not contain procedural code.

[gavofyork]

Generally looks like a reasonable direction (modulo the comment).

This should probably go in XCMv4 though since it's a major API breakage.

[koute]

This should probably go in XCMv4 though since it's a major API breakage.

@gavofyork Hm... well, although it is a source-level API breakage the ABI will stay the same (Encode and Decode behave the same as they did) so on-chain this shouldn't break anything. It's somewhat unfortunate to forever leave the V2 and V3 with those huge types just because of source-level API incompatibility while in other places we break source-level API compatibility all the time.

I'm not saying we shouldn't care about API-level backwards compatibility, we definitely should, however in my opinion fixing this is worth the API breakage. Having such huge types is a potential performance trap and risks triggering bugs like these not only in our code but in our users' code.

So personally I would suggest landing this and, if we're worried about how it will affect downstream users, I could maybe write a migration guide explaining how to update the code to the new API (which is fairly easy, albeit maybe somewhat tedious) and we'd attach that to the release notes?

But it is up to you; if you don't want to break the API then I can update this PR to only include non-breaking changes in preparation for V4, but obviously this won't fix the underlying issue, just make it easier to do this when V4 lands.

[gilescope]

I note that we currently need to box Multilocations when we want to use them in Call enums because the Call memory size is enforced (by a test) to be max 1kb.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-43/3158/3

[KiChjang]

I think it's best to do this on XCMv4. While it's true the binary interface didn't change, the programming interface did, and it does require some effort by XCM developers to change to the new format.

[gavofyork]

We might reasonably make XCMv4 an API-only change (for this) and deliver NOW, rather than waiting around indefinitely for the rest of v4 to materialize. The new instructions can be done as a v5.

[KiChjang]

Okay, so just to clarify: release v4 now containing this change, and retarget all existing RFCs to v5? Sounds like we should also pair it with some renaming changes.

In any case, this means that this PR needs to create a new folder for v4 and make the changes there, rather than modifying existing v2 and v3 type definitions.