Ensure that we are still sending large messages over the bridge

[svyatonik]

At our test deployments we generate max-size messages sometimes. It is generated here:
https://github.com/paritytech/parity-bridges-common/blob/master/relays/bin-substrate/src/cli/encode_message.rs#L73

We need to check, whether they are actually transferred over the bridge after #1983 . Now an XCM message needs to have a special prefix to be sent to the message lane and it seems this large message doesn't have it.

[svyatonik]

2023-04-26 10:54:30.095 DEBUG tokio-runtime-worker sc_basic_authorship::basic_authorship: [Parachain] [0x87d8eb9191dbec45a47c848bbfe41dfdc902ef1c664c977a2dba0cb2a3fdd20b] Invalid transaction: Error at calling runtime api: Execution failed: Execution aborted due to trap: host code panicked while being called by the runtime: Failed to allocate memory: "Requested allocation size is too large"
WASM backtrace:
error while executing at wasm backtrace:
    0: 0x20daff - <unknown>!sp_io::allocator::extern_host_function_impls::malloc::hd4775bf217cf74fb
    1: 0xf3952 - <unknown>!alloc::raw_vec::finish_grow::h4616ce65be0fb092
    2: 0xf51d1 - <unknown>!alloc::raw_vec::RawVec<T,A>::reserve_for_push::hcb079bd341241880
    3: 0x39678 - <unknown>!parity_scale_codec::codec::decode_vec_with_len::h4e6a49b3fb610851
    4: 0x1085ce - <unknown>!xcm::_::<impl parity_scale_codec::codec::Decode for xcm::VersionedXcm<RuntimeCall>>::decode::ha51cc4dd551adc0e
    5: 0xb8bac - <unknown>!<xcm_builder::universal_exports::BridgeBlobDispatcher<Router,OurPlace> as xcm_builder::universal_exports::DispatchBlob>::dispatch_blob::h7f4a2bb7671af2a9
    6: 0x1af67c - <unknown>!<bridge_runtime_common::messages_xcm_extension::XcmBlobMessageDispatch<SourceBridgeHubChain,TargetBridgeHubChain,BlobDispatcher,Weights> as bp_messages::target_chain::MessageDispatch<<SourceBridgeHubChain as bp_runtime::chain::Chain>::AccountId>>::dispatch::h4aded93477bd5e67
    7: 0xbfcc1 - <unknown>!pallet_bridge_messages::inbound_lane::InboundLane<S>::receive_message::h4f4ec90cbb6d4945
    8: 0x15c4b7 - <unknown>!frame_support::storage::transactional::with_storage_layer::h1846f9c70967c1cc
    9: 0xcf2f3 - <unknown>!<pallet_bridge_messages::pallet::Call<T,I> as frame_support::traits::dispatch::UnfilteredDispatchable>::dispatch_bypass_filter::{{closure}}::hb177e5f889e78f6a
   10: 0xd1a68 - <unknown>!environmental::local_key::LocalKey<T>::with::h101b9f88c3a85eed
   11: 0x194a17 - <unknown>!<rialto_parachain_runtime::RuntimeCall as frame_support::traits::dispatch::UnfilteredDispatchable>::dispatch_bypass_filter::h878ecdf09ad0d485
   12: 0x196558 - <unknown>!<rialto_parachain_runtime::RuntimeCall as sp_runtime::traits::Dispatchable>::dispatch::h88923c4aa4b58671
   13: 0xff863 - <unknown>!<sp_runtime::generic::checked_extrinsic::CheckedExtrinsic<AccountId,Call,Extra> as sp_runtime::traits::Applyable>::apply::he461cb20672a522b
   14: 0x1a83ec - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::apply_extrinsic::hcc6013e452935110
   15: 0x181d34 - <unknown>!BlockBuilder_apply_extrinsic

[serban300]

The problem doesn't reproduce when using native execution . It occurs only when running with --execution wasm. That's probably why it doesn't occur on millau and rialto.

And more specifically it occurs when decoding the XCM ClearOrigin instructions vec here.

The problem is that mem::size_of::<Instruction<Call>>() is 1472. And if we send for example 30000 ClearOrigin instructions it tries to allocate 30000 * 1472 =~ 44mil bytes + probably some buffer =~ 60mil bytes total which goes beyond the wasm VM limits.

The size of Instruction<Call> enum should be the size of it's biggest variant, but still 1472 seems huge. Trying to understand why so much.

[serban300]

The size of Instruction<Call> is actually 1427:

• The size of NetworkId is 48 (this is the biggest variant = 8 (discriminator) + 8 (u64) + 32 ([u8; 32]))
• The size of Junction is 88 (this is the biggest variant = 8 (discriminator) + 48 (NetworkId) + 32 ([u8; 32]))
• The size of Junctions is 704 (this is the biggest variant = 88 (Junction) * 8)
• MultiLocation = 712
  ...
• MultiAssetFilter = 720
• Instruction<Call> has variants of this form that contain both MultiLocation and MultiAssetFilter. And when adding up everything => 1472

The issue didn't reproduce with native execution probably because in the native environment we can allocate enough memory.

We need to have a different approach for sending max-size messages. Maybe fix the old one.

[serban300]

Fixed by #2103