Fix deadlock on close() with congested server.

[dpratt]

The call BlockingRPCContinuation#getReply used in the close() method of ChannelN does not specify a timeout. If the server is congested, this call to close() can (and does) block indefinitely and eats up the current thread.

From an API point of view, a close() method should really have a timeout associated with it, and if the server doesn't respond with a cleanly closed connection, the channel should just be discarded.

[michaelklishin]

Thank you. If you have a moment, we'd consumer an API extension that introduces a close() version with a timeout, against the same branch.

[michaelklishin]

I've modified this a bit: now the exception will be re-thrown if you use close() but will be ignored for abort() (just like in every other case). I hope this makes sense.

[dumbbell]

Since RabbitMQ 1.5.0.

[katielim]

ChannelN.basicCancel can also hang since it calls getReply without timeout value.
Can we add a similar change in basicCancel as well?

[michaelklishin]

@katielim it's not as clear cut as for Connection#start and channel closure. The reason being, if RabbitMQ applies TCP back pressure, basic.cancel response will be delayed but nonetheless will be sent after basic.cancel itself is read from the socket and processed. This means we need to adapt our continuations implementation to somehow handle this.

For connection negotiation and channel/connection closure, any exception can be treated as fatal. Otherwise I have no objections to having timeouts for more operations.

See also #55, this should make the lack of timeouts for channel methods somewhat less annoying.