Add minimum interval between consecutive HTTP requests

[amasolov]

Summary

HDFury devices run an embedded web server with limited resources (similar to ESP32-class devices). When the Home Assistant integration polls for data every 60 seconds, it fires 4 HTTP GET requests in rapid succession (brdinfo.ssi, infopage.ssi, confpage.ssi, cecpage.ssi). Over time, this rapid-fire pattern can exhaust available sockets on the device's embedded HTTP server, causing it to become unresponsive and eventually crash (requiring a power cycle to recover).

This is the same class of issue seen in ESP-IDF based web servers (e.g. esphome/esphome#12481) where rapid polling without request spacing leads to httpd_accept_conn: error in accept (23).

Changes

• Add _request_interval (default 1 second) to the HDFuryAPI class that enforces a minimum delay between any two consecutive HTTP requests
• The interval is applied inside _request() so it covers all read and write operations uniformly
• The existing _debounce_delay (which only gates reads after writes) is preserved unchanged
• _last_request_time is updated even on errors, so the interval is still respected when the device is struggling
• Added tests for the new interval behavior (all 70 tests pass, 100% coverage maintained)

Impact

• Each polling cycle now takes ~4 seconds instead of <1 second (4 requests × 1s interval)
• This is well within the 60-second polling window and has no user-visible impact
• Significantly reduces the risk of socket exhaustion on the device firmware

Testing

• All existing tests pass unchanged
• Three new tests verify the interval behavior:
  • test_request_interval_spaces_consecutive_requests — confirms sleep when called too fast
  • test_request_interval_no_sleep_when_enough_time_elapsed — confirms no unnecessary delay
  • test_request_updates_last_request_time — confirms timestamp tracking

[glenndehaan]

Hi @amasolov,

Thank you for the contribution. I would suggest we utilize the debounce globally during a request and not creating a new function that now does the same thing as the debounce. Since right now both the old debounce and new request internal both keep track of requests delays on commands (since commands utilize the same _request function). So for me I would suggest we keep the debounce but utilize it in the way you proposed in this PR.

Kind regards,
Glenn de haan

[amasolov]

Thanks for the feedback! I've reworked this to use the existing _debounce_delay globally as you suggested.

Changes in this update:

• Removed the separate _request_interval mechanism entirely
• Moved _wait_for_debounce() into _request() so it applies uniformly to all HTTP requests (reads and writes)
• Renamed tracking from _last_command_time to _last_request_time since we now track all requests
• Removed the per-method _wait_for_debounce() calls from get_board(), get_info(), get_config()
• _send_command() no longer separately tracks time (handled by _request())

The result is one clean mechanism: every request waits at least _debounce_delay seconds since the last request completed, regardless of whether it's a read or write. This keeps the device's embedded web server from being overwhelmed during polling cycles.