Resource overrun in `server::Handle::data()`

[dsche]

We have observed a rather worrying memory exhaustion behaviour in russh==0.61, triggered by the following use case:

1. Create a Server that listens to connections.
2. On a new connection, grab a session.handle(), and pump it with data (something that can happen if SSH is used to proxy data transfers).
3. Observe that even if handle.data(channel, response).await returns, this is not a guarantee that the output buffer is flushed or even limited. In our case, we have attempted to transfer ~3GiB worth of data, all of which ended up in memory, potentially leading into OOMs.

Our conjecture is that the culprit is server::Session::data() hands the data directly off to Encryped::data_with_writer(), which, inturns, executes channel.pending_data.push_back((buf0, None, 0));. channel.pending_data is an unbounded VecDeque, with no checks on its maximum size, and this applies no backpressure on the sender.

[dsche]

Some updates upon further investigation: It seems that forcing Encrypted::flush() does not lead to the desired effect of blocking until the buffer is empty. It turns out that in our case, down the call stack, data_noqueue is called, with channel.recipient_window_size == 0, which effectively leads to writes of size zero. As far as I understand the SSH protocol, this is by design, as the recipient explicitly can declare how much data they can accept. However, as this flush() apparently does not block, there is no backpressure exerted on the sender, which leads to an unlimited queue growth.

The question is whether this is by design in the russh library. I would conjecture that it would make sense to add backpressure since the user-facing code might not need to care about lower level details like flow control. Specifically this affects the code path outside the request-response loop, as server::Handle::data() directly feeds data into the outbound queue, which can happen if we spawn an asynchronous task that just pumps data into server::Handle::data().