Migrate to the ieee80211_crypto_key_*() routines.
Should be no functional change.

Locally tested:

* RTL8821AU, STA mode

Differential Revision:	https://reviews.freebsd.org/D52712

the firmware should be sending these.

Differential Revision:	https://reviews.freebsd.org/D52298
Reviewed by: bz

Locally tested:

* rtl8821/rtl8812au (STA)

This should both enable the sequence number offloading and disable
the net80211 TX lock from being acquired/released/checked.

Locally tested:

* RTL8812AU, STA mode

Reviewed by: bz
Differential Revision:	https://reviews.freebsd.org/D52301
Differential Revision:	https://reviews.freebsd.org/D50693

The initial thought of migrating the LinuxKPI 802.11 enum into net80211
for shared use did not work out well.  Currently in the need for yet
another adjustment, I decided to undo/de-couple net80211 and
LinuxKPI 802.11 again.

The enum name now gets used in LinuxKPI based wifi drivers and it
turns out it is spelt differntly than what I used initially.
This creates a conflict.

net80211 still in the need to be able to express BW_320 in an uint8_t
will likely be fine with the current solution as well.  Rename the
enum and prefixes in net80211 to "net80211" instead of "ieee80211".
Apart from the names/prefix we leave the values the same.

In LinuxKPI add the enum with the expected name and use it there
throughout to make modern versions of LinuxKPI based wifi drivers
compile.

Sponsored by:	The FreeBSD Foundation
Fixes:		ca389486a9599, 2c8b0d6205f6f
MFC after:	3 days
Reviewed by:	adrian
Differential Revision: https://reviews.freebsd.org/D52064

We can and do receive > 4 KiB frames in the RX path (A-MSDU frames
can be up to 11KiB.)  At least one user has reported seeing this
and having it break their traffic flows.

Use m_get3() to try and grab an mbuf jumbo cluster.

This may not be the best permanent solution, but it at least will
fail for frame sizes we expect to see up and including the largest
A-MPDU frame (11Kib)  and keep a counter if it can't allocate, versus
just returning NULL because it's too large (and not keeping counters.)

Differential Revision:	https://reviews.freebsd.org/D50049
PR:	kern/286366
Reviewed by:	bz

jrtc27@freebsd.org reported that DHCP wasn't working on some
networks.  She dug into it and found that the RTL8812AU/RTL8812AU
NICs seem to be failing UDP frames w/ a zero checksum, which is
a valid "there's no checksum" checksum.

So, just pass those frames up the stack and let the IP stack
deal with it.  If the hardware claims the frames did pass TCP/UDP
checksum then still mark those frames with the checksum offload
bits.

PR:	kern/285387
Differential Revision:	https://reviews.freebsd.org/D49628

The RX filter wasn't enabling BAR frames, so we weren't receiving them
during normal operation.

Jessica noticed we WERE getting BAR frames, but only when promisc mode
is active.  Which is a different set of bugs, but it did highlight
the differences here.

Differential Revision:	https://reviews.freebsd.org/D49596
PR: kern/285822

I'm testing this with rtwn(4) NICs right now, so enable it here.

Locally tested:

* RTL8812AU / RTL8821AU, STA mode (with some wpa_supplicant.conf
  shenanigans to force GCMP as the pairwise key to an OpenWRT AP
  configured to use GCMP but without requiring MFP.)

Differential Revision:	https://reviews.freebsd.org/D49190
Reviewed by:	bz

Migrate the transmit path to use ieee80211_node_get_txrate(), and handle
VHT rates.

Nothing is currently setting VHT rates, but the driver should now
be ready.

Differential Revision:	https://reviews.freebsd.org/D48606
Reviewed by:	bz

This just mechanically converts things.

* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
  doesn't report it up.

Differential Revision:	https://reviews.freebsd.org/D48602
Reviewed by:	bz, thj