yamux: Update yamux with window tuning and backport fixes

[lexnv]

This PR updates the internal yamux crate to include the following:

• yamux window auto tuning similar to QUIC
• Wake up readers to not miss EOF
• pending frames are replace with pending read and write frame for propagating backpressure

Updates are backported from upstream to work with the current yamux::Control and yamux::ControlledConnection.
The Control and ControlleConnection are used by litep2p and have been removed by upstream. This will lead to a major litep2p refactor which may take significantly longer than backporting.

[dmitry-markin]

Can you remind why we carry our own yamux fork with litep2p? I remember some functionality was removed from the upstream?

May be we can extract yamux as litep2p-yamux and try keeping it in sync with upstream, only with the needed patch applied? Backporting every yamux change in-tree of litep2p seems to be a lot of work, and they will diverge sooner or later anyway.

[altonen]

Yamux was included in litep2p because there was a memory leak which had been fixed in a later version but that version also had quite significant API breakage which would've required at least a partial rewrite of TCP/WebSocket connections handlers. More context here: #55

[lexnv]

I've also had a brief look, the refactor needed to adjust to the upstream API is quite involved. We can probably handle this as a follow-up post stabilization in substrate 🙏

I think multistream-select has a similar story, however I'm not sure what changed in terms of compatibility there

[dmitry-markin]

Was this backported from the upstream yamux?

[lexnv]

I've backported all commits IIRC, will double check to be sure. Cherry-picking was not an option since we diverge in the API

[dmitry-markin]

Was 066dae3 cherry picked completely from upstream yamux? If not, what parts were updated manually?

[dmitry-markin]

Was 8301fff cherry-picked from the upstream? What parts were manually modified?