Naive fix for sending sized messages

[serban300]

Fix sized messages by adding an estimated xcm executor overhead.

This can be just a temporary fix, or if it's good enough we can leave it like this. @svyatonik what do you think ? How precise does the payload size need to be ? I see that we already have other estimation here for example.

[svyatonik]

This can be just a temporary fix, or if it's good enough we can leave it like this. @svyatonik what do you think ? How precise does the payload size need to be ? I see that we already have other estimation here for example.

In ideal world it needs to be the maximal possible (i.e. compute_maximal_message_size). The general idea is to prove that we are able to deliver messages that our runtime accepts (we now have the only check when we are queening the message - it is the size check). So if we are accepting messages of 1_024 bytes, but we can only deliver 1_023 byte messages, it'll mean that the bridge can break when such message is sent.

There's a lot of assumptions in the code. E.g. the bridge_runtime_common::messages::target::maximal_incoming_message_size method assumes that everything except the message (i.e. storage trie nodes, signed extension data, ...) will fit into 1/3 of maximal extrinsic size. So we leave 2/3 of max extrinsic size to the message itself.

But rhe code you're referencing is about a different situation. This is for cases when messages are sent from the chain where max transaction size is lesser than 2/3 of target chain max transaction size. For our deployments, it is Millau -> Rialto. Millau has 2Mb blocks and Rialto has 5Mb blocks. So we can't send 2/3 * 5Mb messages from Millau to Rialto because the message will be rejected at Millau (because transaction is too large). For the other direction (Rialto -> Millau), IIRC we were using messages of exactly compute_maximal_message_size bytes (but I can't guarantee that :) ).

So I suggest to try to use message generation infrastructure from #2064, but use the ExportMessage instruction instead of ClearOrigin. IMO it'll generate messages that are closer to the compute_maximal_message_size limit than the current one. But feel free to ignore the suggestion - your approach is good enough too (I"m hitting approve and let you decide).

[serban300]

compute_maximal_message_size

Ok, thank you for the details ! Makes sense. I will try to fix this then.

[serban300]

Closing this PR for the moment and will open a new one later.