Update Rust crate tokio-tungstenite to 0.20

[oxide-renovate]

This PR contains the following updates:

Package	Type	Update	Change
tokio-tungstenite	workspace.dependencies	minor	0.18 -> 0.20

---

Release Notes

snapview/tokio-tungstenite (tokio-tungstenite)

v0.20.1

Compare Source

• Fix RUSTSEC-2023-0053.
• Fix transitive CVE-2023-43669 from tungstenite.

v0.20.0

Compare Source

• Change the buffering behavior for Sink::send() and Sink::feed(), see tungstenite's changelog for more details.

v0.19.0

Compare Source

• Allow users to enable/disable Nagle algorithm when using connect() helpers.
• Improve the behavior of the Sink for the WebSocketStream, so it does not return an error when it’s not necessary (when poll_flush() is called on a connection that has just been closed).
• Workaround an issue where rustls TLS backend expected domain in a certain format and reject IPv6 addresses if they contained square brackets in them.
• Update dependencies and remove unused errors.

---

Configuration

📅 Schedule: Branch creation - "after 8pm,before 6am" in timezone America/Los_Angeles, Automerge - "after 8pm,before 6am" in timezone America/Los_Angeles.

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[sunshowers]

Asking for review because the semantics of tokio-tungstenite have changed from tracking a max send queue of messages, to a max write buffer size. Based on the default 128KB default write buffer size, I think a max write buffer size of 2MB should be good. (I figure most messages are pretty small and 2MB corresponds to 4096 512-byte messages).

[oxide-renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠ Warning: custom changes will be lost.

[lifning]

agreed, 2MiB ought to be enough for anyone -- at least, it's the same total amount of serial spew history that we keep buffered in propolis itself, and linux guests generally run the UART at 115200 baud (14.4KB/s), so it should be exceedingly rare that a brief connection hiccup turns into a spurious buffer full error.