Update tokio-tungstenite requirement from 0.15.0 to 0.16.0

[dependabot]

Updates the requirements on tokio-tungstenite to permit the latest version.

Changelog

Sourced from tokio-tungstenite's changelog.

0.16.0 (Unreleased)

• Add a function to allow to specify the TLS connector when using connect() like logic.
• Add support for choosing the right root certificates for the TLS.
• Change the behavior of the connect() so that it fails when using TLS without TLS feature.
• Do not project with Unpin.
• Update the dependencies with important implications / improvements.

0.15.0

• Update the tungstenite-rs version to 0.14.0, check tungstenite-rs release for more details.

0.14.0

• Support for rustls as TLS backend.
  • The tls feature was renamed to native-tls and uses a OS-native TLS implementation.
  • A new native-tls-vendored feature that uses native-tls but forces to build a vendored version (mostly for openssl) instead of linking against the system installation.
  • New rustls-tls feature flag to enable TLS with rustls as backend.
  • stream::Stream was renamed to MaybeTlsStream and wraps a rustls TLS stream as well now.
  • If both native-tls and rustls-tls are enabled native-tls is used by default.
  • A new Connector was introduced that is similar to the previous TlsConnector but now allows to control the used TLS backend explicitly (or disable it) in client_async_tls_with_config.

0.13.0

• Upgrade from Tokio 0.3 to Tokio 1.0.0.

Commits

• 84c7488 Update the changelog
• 4298e9e Bump version
• 7a520c2 Merge pull request #198 from dnaka91/rustls-0.20
• ec14883 Update dependencies to official releases
• 49d4e0b Upgrade to rustls 0.20
• b40114e Re-port #90 (#194)
• 2bfd4cd Fix the echo server example to prevent ConnectionClosed error (#189)
• d566387 Update the changelog
• cb24743 Fail with TlsFeatureNotEnabled if connecting to wss without the feature (#186)
• 171a452 Merge pull request #184 from dnaka91/rustls-roots
• Additional commits viewable 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)

[clux]

welp, well, it "works". but it doesn't upgrade with cargo upgrade --all :/

[kazk]

welp, well, it "works". but it doesn't upgrade with cargo upgrade --all :/

Do you mean all outdated crates in a single PR?

[clux]

No, I mean bump the single dependency in all crates (currently it does single dependency in one crate). Otherwise we end up with multiple versions (which we now block on cargo deny against).

[clux]

Actually, that might not be true. I just assumed it was doing per crate. This PR does the only crate it needs to update it, but cargo deny check seems to be confused about it for lockfile reasons 🤔

[kazk]

Yeah, the duplicate version is because of transitive dependencies (warp depends on older version).

[nightkr]

Maybe we should just exclude examples from the dupe check?

[clux]

I think that makes sense for cargo-deny, but I am also happy with keeping it there. It's nice to limit dupes when possible (as in the most recent PR that duplicates tracing-subscriber) to avoid double compiles.

It looks like dependabot should be able to upgrade all workspace crates from quick scans on their issues: dependabot/dependabot-core#1207 EDIT: that is what it is doing.

[dependabot]

Superseded by #750.