If heartbeats are disabled, do not use a read timeout when reading frame header

[carlhoerberg]

Bug #519 wasn't quite resolved. If heartbeats are disabled (keepalive
used instead), Bunny would use the default read_timeout when waiting for
next frame, that meant that the connection would be closed with an
exception if there was no activity for 30s.

[carlhoerberg]

Yes, this disables heartbeat timeouts as well as they're intertwined. Suggestions welcomed on how to easiest fix that.

[michaelklishin]

@carlhoerberg I'm not sure I understand the "disables heartbeat timeouts" part. It does interfere with the heartbeat mechanism somewhat, as any socket operation timeout changes do, but they should still work.

I am on the fence about this change. Since it is possible to bump the timeout for the user to a really high value, shouldn't you just do that instead of changing Bunny? FWIW TCP keepalives are not used by the majority of users.

[michaelklishin]

We can make frame header reads use no timeout only if heartbeats are disabled. That's not very elegant but makes most sense to me conceptually. WDYT @carlhoerberg?

[carlhoerberg]

Disabled read_timeout completely now when heartbeat is disabled too. The behavior of connections with heartbeat enabled is unchanged with this patch.

[michaelklishin]

Thanks, I will QA this fairly soon. Probably worth a minor version bump for if we end up merging it.

[michaelklishin]

After giving it some thought I think it makes sense to disable TCP socket read timeouts if heartbeats are disabled. The two are interconnected in practice. I left a note about TCP keepalives and a link to RabbitMQ heartbeats guide in the change log.

Thank you, @carlhoerberg.