[suggestion]: Consider changes in MAX_MESSAGE_LENGTH

[Erigara]

With large enough Genesis we cant send it through network to other peers through network.

Options:

• Increase constant value;
• Make configuration parameter (not sure if possible);
• Remove at all.

[appetrosyan]

We can make an exception for genesis. But keep the limit.

Otherwise I think we should change it to a mandatory configuration parameter that is either a non-zero size in MB, or no limit. The user should be the one deciding, but we need to give good docs.

Ideally it should say: "if you want to be on the safe side, set it to 0, examine your network, and then set it to double the largest block". And that "running without a limit opens you up to a DoS attack".

[Erigara]

@appetrosyan, I'm not sure that making exception for genesis is feasible solution, this check happens on another abstraction layer where iroha doesn't make distinction between messages it send.

I agree with configuration parameter approach it could be smt like Option<NonZeroU64>, however i should mention that we already had limitation guards on higher layer (limitation on number of instructions and blob size), so seems this guards check the same thing with different angle.

[Erigara]

Was decided to remove this constraint at all as short term solution, long term solution would be introduction of bootstrap peers and hot reloading.