crypto/noise: Improve stability of websockets by fixing AsyncWrite implementation

[lexnv]

The PR fixes a AsyncWrite::poll_write implementation of the crypto/noise sockets that causes panics in rust-yamux and leads to unnecessary connection closure and instability:

• T0: poll_write is called with buffer of len 512 bytes
  • the implementation encrypt data and buffers it
  • because the io socket is not ready, poll pending is returned.
• T1: tokio_tungstenite (or other component) decides that a new payload must be sent (usually a PONG frame) of len 12 bytes
  • because the inner buffers contain the previous message, upon flushing the size of the older message is returned (ie 512)
  • rust-yamux uses the 512 bytes to index a buffer of 12 bytes (as expected by the second poll_write with buffer 12)
  • This caused frequent panics on the websocket implementation, which is currently addressed as abrupt connection termination

This PR fixes the AsyncWrite contract violation by effectively decoupling the encryption from the writing steps.

• the inner buffers are drained as much as possible (until the socket returns poll pending)
• The provided message is encrypted into the inner buffer if it has capacity and the number of bytes is returned immediately
• a subsequent poll_write or poll_flush or poll_close will propagate the encrypted buffered data to the underlying socket

Previous fixes:

• yamux/frame: Ensure frame io does not panic on invalid write results libp2p/rust-yamux#202
• frame/io: Introduce Poisoned state for WriteState libp2p/rust-yamux#211

The fixes are still needed since the tokio-tungstenite (websocket crate) was not properly scoped and may exhibit similar behavior.

cc @paritytech/networking

[dmitry-markin]

Cool finding and good job here!

[dmitry-markin]

It looks like we haven't registered the waker to wake up the task once we have space in the buffer (and poll_write above might not wake as as well if it returned Ready). May be we don't need this if block at all to not return Poll::Pending?

[lexnv]

Yep, if the poll_write returns Poll::Ready, then we must rely on the fact that:

• one chunk+overhead has sufficient space to fill into the encrypt_buffer