Caching of tokio backend reqwest http client

[MaxHeimbrock]

Summary

With the native-tokio feature (enabled via livekit-api/signal-client-tokio → livekit-net/native-tokio → internal __native-tokio marker), NativeTransport::request in livekit-net/src/native/mod.rs:110 uses reqwest for HTTP. Before this branch, it built a reqwest::Client::new() inside every request; This PR replaces that with a process-wide static LazyLockreqwest::Client, so all requests share one client — and with it reqwest's internal hyper connection pool (keep-alive TCP/TLS connections). The async backend (isahc) is untouched.

Proof by benchmark

I built a throwaway bench crate (in the session scratchpad, not your repo) that runs N sequential GETs two ways: cached goes through the real livekit_net::testing::native_http_client() code path, fresh replicates the old code verbatim. A local server counts accepted TCP connections; a second scenario hits a real HTTPS endpoint so a genuine TLS handshake is in play.

┌─────────────────────────────────────────────┬──────────────┬─────────────────────────────┐
│                  Scenario                   │ Cached (new) │   Fresh per-request (old)   │
├─────────────────────────────────────────────┼──────────────┼─────────────────────────────┤
│ Local plaintext, 1000 reqs — time/req       │ 58 µs        │ 95 µs (~1.6× slower)        │
├─────────────────────────────────────────────┼──────────────┼─────────────────────────────┤
│ Local plaintext — TCP connections opened    │ 1            │ 1000                        │
├─────────────────────────────────────────────┼──────────────┼─────────────────────────────┤
│ Real HTTPS (Cloudflare), 50 reqs — time/req │ 7.0–9.8 ms   │ 36.5–41.4 ms (~4–5× slower) │
├─────────────────────────────────────────────┼──────────────┼─────────────────────────────┤
│ Peak RSS (local run)                        │ 8.3 MB       │ 8.5 MB                      │
└─────────────────────────────────────────────┴──────────────┴─────────────────────────────┘

The connection count is the smoking gun: the old code opened a brand-new TCP connection for every single request, the cached client opened exactly one and reused it. On loopback that only costs ~40 µs per request, but against a real HTTPS server — which is what token endpoints are — every fresh connection pays DNS + TCP + TLS handshake, making the cached client 4–5× faster per request (I ran it in both orders to rule out warm-up bias).

Alternative

The alternative is storing the Client on NativeTransport instead of in a static — same pooling benefit per registered transport, but scoped to the object's lifetime rather than the process.

[github-actions]

Changeset ✓

This PR includes a changeset covering all affected packages:

Package	Bump
livekit	patch
livekit-api	patch
livekit-ffi	patch
livekit-net	patch
livekit-uniffi	patch

[jhugman]

This looks fine to me. FWIW the intention is that client SDK should call set_ws_client and set_http_client to re-use the client's networking stack and certificate store.