Yamux deadlock when splitting stream

Nobody has claimed this yet.

https://github.com/stormshield-pj50/yamux_race is a small example that reproduces a deadlock in Yamux when a stream is split.

The program launches a server and a client. The client establishes a TCP connection to the server and opens a single Yamux stream. Both the server and the client then split that stream into a read half and a write half, and each side spawns two asynchronous tasks: one that continuously writes to the stream and another that continuously reads from it.

After the writer has performed ten writes, the deadlock occurs. The issue appears to arise when the internal MPSC sender on the Yamux stream becomes full. At that point the writer task is never woken up again because the reader registers another waker when it sends a WindowUpdate frame on the MPSC channel. The Yamux internal MPSC sender is shared by both the reader and the writer tasks. The MPSC implementation of the future crate wakes up only the last waker. So the writer task waker is definitely lost.

The deadlock pattern is reproduced by this simple example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5fb34c6f773d51b0fd12bba6a2b5d798

Tokio references this issue : https://github.com/tokio-rs/tls/issues/40

Start with the linked yamux_race example and Rust Playground reproducer, then trace the split stream's reader and writer tasks through the shared internal MPSC sender. Confirm the deadlock after ten writes and verify that the reproducer completes without hanging when both halves continue reading and writing.

Written by the indexing model from the issue text.