Update yamux requirement from 0.8.1 to 0.9.0

[dependabot]

Updates the requirements on yamux to permit the latest version.

Changelog

Sourced from yamux's changelog.

0.9.0

• Force-split larger frames, for better interleaving of reads and writes between different substreams and to avoid single, large writes. By default frames are capped at, and thus split at, 16KiB, which can be adjusted by a new configuration option, if necessary.

• Send window updates earlier, when half of the window has been consumed, to minimise pauses due to transmission delays, particularly if there is just a single dominant substream.

• Avoid possible premature stream resets of streams that have been properly closed and already dropped but receive window update or other frames while the remaining buffered frames are still sent out. Incoming frames for unknown streams are now ignored, instead of triggering a stream reset for the remote.

0.8.0

• Upgrade step 4 of 4. This version always assumes the new semantics and no longer sets the non-standard flag in intial window updates.
• The configuration option lazy_open is removed. Initial window updates are sent automatically if the receive window is configured to be larger than the default.

0.7.0

Upgrade step 3 of 4. This version sets the non-standard flag, but irrespective of whether it is present or not, always assumes the new additive semantics of the intial window update.

0.6.0

Upgrade step 2 of 4. This version sets the non-standard flag, version 0.5.0 already recognises.

0.5.0

This version begins the upgrade process spawning multiple versions that changes the meaning of the initial window update from "This is the total size of the receive window." to "This is the size of the receive window in addition to the default size." This is necessary for compatibility with other yamux implementations. See issue #92 for details.

As a first step, version 0.5.0 interprets a non-standard flag to imply the new meaning. Future versions will set this flag and eventually the new meaning will always be assumed. Upgrading from the current implemention to the new semantics requires deployment of every intermediate version, each of

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)