Do not lose data on channel close.

[Lukasa]

Motivation:

We didn't notice this as much when we had autoRead turned on and the
broken data fast path, but now that we don't it has become apparent that
we can see data loss if CHANNEL_CLOSE arrives while we're queueing
reads. That's not good!

Here we decide to adopt the same pattern as NIO does with TCP channels:
if we receive a hard-close, we will deliver all pending data, even if
you have not got an outstanding read(). This avoids data loss, while
allowing us to rapidly drop resources that are potentially in short
supply. In this case, if the remote peer doesn't care about this channel
anymore, we should really stop holding it open ourselves.

Modifications:

• No longer drop reads in any circumstance, always deliver them.
• Wrote some tests.

Result:

No data loss!

[Joannis]

Does the same expectation apply to the parent channel I.E. the SSH protocol itself? I'd say it's an expectation. A search of mine doesn't reveal any such tests so far.

[Lukasa]

The answer is yes it does. There is less risk here because the NIOSSHHandler does not buffer inbound messages and must deliver them in order. As a result, the only way this can become a problem is if we re-entrantly receive channelInactive, which we should not do in a well-functioning pipeline. In those cases, we can see data loss, but we also cannot do anything about it because we didn't know about the data to begin with.