[RFE] max_retry_band should also limit band steering BSS-TM requests

[pafernanr]

Problem

Devices that are 2.4 GHz-only but respond to BSS-TM requests with status_code=0 (accept) cause usteer to retry band steering indefinitely. This is common with cheap IoT WiFi stacks (Tuya/Beken, ESP-based) that blindly acknowledge BSS-TM without being capable of transitioning to 5 GHz. The result is persistent log spam on the AP for as long as the device is connected:

hostapd: phy0-ap0: BSS-TM-RESP 77:77:77:77:77:77 dialog-token=0 status-code=0
hostapd: phy0-ap0: BSS-TM-RESP 77:77:77:77:77:77 dialog-token=0 status-code=0
hostapd: phy0-ap0: BSS-TM-RESP 77:77:77:77:77:77 dialog-token=0 status-code=0
...  (repeats every ~2 seconds, indefinitely)

Proposal

Extend max_retry_band to also limit band steering BSS-TM requests: track a per-station retry counter, skip sending when the limit is reached, reset on disconnect.

This reuses an existing config knob with a sensible default (5), needs no new configuration, and is backward compatible — setting max_retry_band=0 preserves the current unlimited behavior.

[pafernanr]

PR #18 (commit 373571e) takes a cleaner approach — it skips band steering entirely for stations where seen_5ghz is false. Since 2.4G-only devices can never be seen on 5 GHz, this prevents the BSS-TM spam at the source.

I also developed a complementary fix that enforces max_retry_band on BSS-TM requests (stops after N attempts for devices that accept but never move). This would cover a more niche case: dual-band devices that have been seen
on 5 GHz but still accept-and-ignore BSS-TM. However, with PR #18 in place, that scenario is marginal enough that I won't submit a separate PR for it.

Note: I was running the stock OpenWrt 24.10.5 usteer package (2022.08.18~7d2b17c9), which is significantly behind the current master. Some of my initial analysis of max_retry_band and steer_reject_timeout behavior may not
reflect the latest code. Apologies for any confusion.

Closing in favor of PR #18.