update tokio-tungstenite and tokio-rustls

[Be-ing]

split off from #609

[Be-ing]

tokio-rustls 0.24 has been dragging in an old rustls 0.21.12 in addition to the rustls 0.23 used by the rest of the dependency tree 🙈

[ladvoc]

Currently, E2E tests in CI run with a local SFU in dev mode without TLS. In order to make sure this doesn't break anything, we need to verify E2E tests pass with a LiveKit Cloud SFU and the rustls-tls-native-roots feature enabled:

LIVEKIT_URL=wss://my-project.livekit.cloud \
LIVEKIT_API_KEY=xxx \
LIVEKIT_API_SECRET=xxx \
cargo test --features rustls-tls-native-roots,__lk-e2e-test -- --nocapture

I'm going to look into what the issue is here, but currently, I get the following runtime error when running E2E tests with TLS:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled. See the documentation of the CryptoProvider type for more information.

[ladvoc]

I think this is the issue:

• How I use CryptoProvider::install_default() ? rustls/rustls#1938 (comment)

[Be-ing]

I think this is the issue: rustls/rustls#1938 (comment)

I think so. livekit-api's rustls-tls-native-roots feature activates reqwest's rustls-tls-native-roots feature, which activates reqwest's __rustls_ring feature, which activates the ring feature of rustls. I think this was not causing a problem before because of the separate old version of rustls being used by livekit-api.

[Be-ing]

@ladvoc any thoughts how to resolve this?

[ladvoc]

Let me take a closer look and get back to you on that.

[Be-ing]

I have an idea that might resolve this: rework #755 to make passing in the TLS connector a required part of Livekit's API and remove all the Cargo feature flags for selecting the TLS backend. @ladvoc what do you think about that?