LinuxKPI: 802.11: band-aid for invalid state changes after (*iv_update_bss)

With firmware based solutions we cannot just jump from an active session
to a new iv_bss node without tearing down state for the old and bringing
up the new node. This likely used to work on softmac based cards/drivers
where one could essentially set the state and fire at will.

We track (*iv_update_bss) calls from net80211 and set a local flag that
we are out of synch and do not allow any further operations up the state
machine until we hit INIT or SCAN. That means someone will take the state
down, clean up firmware state and then we can join again and build up
state.

Apparently this problem has been "known" for a while as native iwm(4) and
others have similar workarounds (though less strict) and can be equally
pestered into bad states. For LinuxKPI all the KASSERTs just massively
brought this problem out. The solution will be some rewrites in net80211.
Until then, try to keep us more stable at least and not die on second
join1() calls triggered by service netif start wlan0 and similar.

PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (2023, partial)
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43725

(cherry picked from commit 2ac8a2189ac6707f48f77ef2e36baf696a0d2f40)