Don't close connection if channel without finished publish is closed about rabbitmq-server

[michaelklishin]

This is a highly hypothetical scenario that only a proxy can run into. Most RabbitMQ users do not use proxies of this kind, so we will only accept this if it introduces zero regressions for throughput (as reported by several long-ish PerfTest runs).

[michaelklishin]

#11210 (comment)

[michaelklishin]

Sorry, the more I think about how this can be done (#11210), the more I find section 4.2.6 to be ridiculous and this change as inevitably risky. We have deviated from the AMQP 0-9-1 spec in the past for practical implementation reasons and questionable or ambiguous decisions in that fronze-in-time spec, and I have no problem with that.

A Hypothetical Algorithm for Protocol-Aware Proxies

What a proxy could do to avoid an exception is something like this:

• Knowing the size of the expected content (zero or more body frames), assume that the any frame arriving in the middle of a publish should be delayed
• After the publish is done, publish all those pending frames

This will not allow clients to "terminate a publish" early but it will be a safe thing to do.

To handle potentially missing body frames, introduce a "flushing timeout" where all pending frames are sent. This would not be a safe thing to do, though, so such timeout would have to match the heartbeat or TCP keepalive timeout used.

It's not the most straighforward algorithm to implement but I honestly don't see why cloudamqp/amqproxy#162 should be solved in RabbitMQ if the user very clearly states that directly connected clients are not affected.