feat(websocket): interruptable wait timeout

[gabsuren]

Based on #607

Previously, calling esp_websocket_client_set_reconnect_timeout() while a reconnection delay was already in progress had no immediate effect this made dynamic backoff strategies unreliable.

---

Note

Medium Risk
Touches the websocket client task’s reconnect timing and FreeRTOS event-group waits; behavior change is localized but affects all auto-reconnect users who change timeout at runtime.

Overview
Reconnect backoff can now be updated while a delay is already running, so dynamic strategies (e.g. exponential backoff on WEBSOCKET_EVENT_DISCONNECTED) take effect immediately instead of waiting for the old fixed sleep to finish.

The client task adds a WAKEUP_BIT on the status event group. esp_websocket_client_set_reconnect_timeout() sets this bit after updating wait_timeout_ms, which ends the reconnect wait early. The wait loop no longer blocks for half of wait_timeout_ms on a fixed timer; it sleeps only for the remaining time until reconnect (or until stop/WAKEUP_BIT). Reconnect eligibility uses >= with uint64_t for the elapsed-vs-timeout comparison. Public API docs drop the old “may not affect active delay” warning and state that an in-progress delay is updated.

^{Reviewed by Cursor Bugbot for commit 2469f63. Bugbot is set up for automated code reviews on this repo. Configure here.}