add ConnectOptions::with_websocket_config for MqttClient (#165)

[bryan-ashby]

Part of #165, as agreed there: a static WebSocket configuration on ConnectOptions, applied on every connect and reconnect. The request modifier will come separately.

Builds on #189 and #191: the headers only reach the wire with #189, and this edits the client's wss:// path that #191 rewrote. Until those merge, the diff includes their commits; the change here is the last commit.

Changes

• ConnectOptions::with_websocket_config(WebSocketConfig), stored as Option<Arc<WebSocketConfig>> (behind transport-websocket). An Arc keeps the connect futures under clippy's large_futures limit.
• MqttClient reads it on every connection attempt. connect_websocket and connect_websocket_secure read it from the client's current options, so automatic reconnects use it too. The URL is replaced by the address passed to connect (crate-private WebSocketConfig::with_url, which validates the scheme like new), and the headers, subprotocols, user agent and timeout are kept.
• wss TLS precedence: a TLS config set on the WebSocketConfig is used as given, except that set_insecure_tls(true) still disables verification. Without one, the stored config from set_tls_config/connect_with_tls applies as in use WebSocketConfig's TLS configuration for wss:// connections (#190) #191.
• WebSocketConfig implements Clone. Its Debug still redacts header values, and ConnectOptions' Debug now includes it.

Tests

tests/client_websocket_config.rs:

• websocket_config_is_sent_on_connect_and_on_reconnect. A loopback ws:// server captures each upgrade request, answers CONNECT with a CONNACK, then closes the connection so the client reconnects. Both requests carry the configured Authorization, mqttv5.0, mqtt and User-Agent, and Host is the address passed to connect rather than the config's placeholder URL.
• websocket_config_tls_is_used_for_wss. With no stored TLS config, the client only completes the wss handshake if the WebSocketConfig's CA is used.

Both fail without the client/inner.rs change.

Locally, on the pinned 1.98.0 toolchain, fmt, clippy (workspace, wasm, and the lib with no features or a single feature), cargo doc -D warnings and the doctests pass. The full suite passes apart from the same machine-only failures noted on #189 and #191. Fork CI: bryan-ashby#3.

🤖 Generated with Claude Code

[fabracht]

Thanks, Bryan, this is what I had in mind. I ran an MqttClient with with_websocket_config against our ws listener, with a placeholder URL, mqttv5.0 and a custom header, and it connects, subscribes and gets its message. Your two tests fail without the client/inner.rs change, as you said.

I made the last few changes myself so we can get it in:

• Merged main into your branch for the conflicts #189 and #191 left behind. Your code is unchanged.
• ConnectOptions has public fields and no #[non_exhaustive], so the new field breaks code that builds it with a struct literal. I checked with a small crate outside the workspace: a literal that compiles against main fails here with missing field websocket_config, and only when transport-websocket is on. I added a Breaking entry for it to the CHANGELOG, like the one for resume_existing_session in 0.41.0, and it will go out in a minor release.
• We run clippy with -W clippy::pedantic, and with the bigger ConnectOptions it flagged nine test calls as large futures, in quic_multistream_integration.rs, broker_quic_integration.rs and clean_start_prebind_subscribe.rs. They're wrapped in Box::pin now.
• parse_websocket_url had landed between is_http_token and its doc comment, so I moved the comment back.

Nothing left for you to do here, merging once CI passes.

[fabracht]

Thanks Bryan, this is merged now.

We added one thing before merging. The client follows a CONNACK redirect (UseAnotherServer or ServerMoved) on its own, and the redirected connection was reusing the WebSocket config, so the custom headers (an Authorization header, for example) went to whatever server the redirect named. Now only the address passed to connect gets the config, and a redirected connection uses the defaults. There's a test for it in client_websocket_config.rs, and the doc comment and CHANGELOG entry say so too. We also took out the inline comments to match the rest of the code.

The red Rust CI run on your fork came from a timing test of ours that counted backend setup time as lock time. That's fixed on main in #216 and has nothing to do with your change.

It'll go out in the next release.