Please apply the rtw88 USB after-DTIM queue fixes to 7.3.y, 6.18.y, 6.12.y and 6.6.y

[Mehmet Fide <mehmet.fide@gmail.com>]

Hi,

please consider these four commits, in this order, for the 7.3.y, 6.18.y,
6.12.y and 6.6.y stable trees:

  c710c7c2e038 ("wifi: rtw88: usb: route bmc frames via the high queue only for DTIM delivery")
  04cc8c59a3d7 ("wifi: rtw88: usb: bound what the driver feeds the after-DTIM queue")
  185971f1b4eb ("wifi: rtw88: usb: only let the frames a dozing station needs use the after-DTIM queue")
  cf8b516f6765 ("wifi: rtw88: widen the ATIM window while an AP interface is up")

They are in mainline since 7.4-rc1. git cherry-pick applies them to
v7.3.4, v6.18.63, v6.12.117 and v6.6.162 without a conflict; on the last
two, one context line of 185971f1b4eb differs in the include block of
usb.c, so patch applies that hunk with fuzz 1. With the four commits,
rtw88 builds without a warning on all four (x86_64 allmodconfig, W=1).

Since 076f786a0ae1 ("wifi: rtw88: Fix AP mode incorrect DTIM behavior"),
in 6.5, an rtw88 USB AP routes every broadcast and multicast frame to the
after-DTIM high queue, which the firmware drains at beacon pace. Ordinary
broadcast and multicast traffic then exhausts the shared TX page pool for
as long as it lasts: every other transmit queues behind the backlog,
authentication responses can leave too late for a station to associate,
and the beacon reserved page download fails ("error beacon valid"). The
first commit stops the unconditional routing; the other three bound and
filter what still takes that path and widen the ATIM window.

Tested on v6.12.114 with an RTL8821CU AP (USB2, hostapd, one Windows
client in maximum power save) and 80 frames/s of broadcast and multicast
sent from the AP. Plain v6.12.114 rtw88: the free page count at 0x240
falls from 411 to 17 within 15 s and stays below 20, the stack gets about
5 of the 80 frames/s out, the beacon reserved page download fails 16
times ("error beacon valid", "failed to download drv rsvd page"), and
unloading the driver afterwards warns "Have pending ack frames!". The
same tree with the four commits: the pool stays above 400, 79 frames/s
go out, no beacon error, and 3 rejoins plus 10 join/ping cycles pass.

Thanks,
Mehmet