Introduce a configurable limit to message size, reduce default to 128 MiB

[hairyhum]

Proposed Changes

Motivation: very large messages can be problematic for Erlang distribution. The distribution message can only be up to 2GB, but there will be some additional data, so the message body should be even smaller.
Another issue is failure detection, which is based on heartbeats. If a message is taking too long to transfer, the cluster nodes can miss the heartbeat and break the cluster.

Things like garbage collection and general performance can also suffer with a bigger message sizes.

Add max_message_size configuration to configure the limit in bytes.
If message is bigger - channel exception will be thrown, just like it was before for messages bigger than 2GB

Default limit is 128MB (134217728 bytes).
There is still a hard limit of 521MB (536870912), see rabbitmq/rabbitmq-common#289.

Types of Changes

• Bugfix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation (correction or otherwise)
• Cosmetics (whitespace, appearance)

Checklist

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• All tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in related repositories

[hairyhum]

Should we consider adding some human-friendly configuration format (for example 128MB), as it is for memory limits?

[michaelklishin]

This means every published message goes through a single group leader process. Please move this to channel state since the value can be assumed a runtime constant.

[hairyhum]

@michaelklishin no, it's using ets tables https://github.com/erlang/otp/blob/master/lib/kernel/src/application_controller.erl#L332
And it does not need to get a group leader, because appliction name is explicit in this case.

[michaelklishin]

Even then, why not make it a constant in the channel state and eliminate several new extra calls that would effectively always return the same value?

[hairyhum]

Fair enough. The value can technically change during a channel lifetime, but that's not a public API, so we can move it to the channel state.

[michaelklishin]

I understand but it is unlikely to be a common event. We also can claim that the updated value (e.g. via rabbitmqctl eval will only take effect for new channels. That's how things work for a few configurable settings already.