Oopsie, forgot to adjust the test for change in roaming signal strength
threshold.

Fixes: 24bbceed9bad ('wifi: roam more aggressively'):

-80dBm is a very weak signal and we should roam sooner.
iwd[1] and iOS[2] default to -70dBm, Android[3] default to -73dBm.
So lets change the roaming threshold to -70dBm.

[1] https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=45a51613c4c24067fe0e35b4c084a50124282b36
[2] https://support.apple.com/en-us/HT203068
[3] https://android.googlesource.com/platform/frameworks/base/+/68a4599a37e07745cbe0d441e29152da388b5baa/core/res/res/values/config.xml#609
    https://android.googlesource.com/platform/frameworks/opt/net/wifi/+/dacacbf69da8844232d938437b3b38471a3d2827/service/java/com/android/server/wifi/ScoringParams.java#218
    https://android.googlesource.com/platform/frameworks/opt/net/wifi/+/dacacbf69da8844232d938437b3b38471a3d2827/service/java/com/android/server/wifi/ScoringParams.java#325
    https://android.googlesource.com/platform/frameworks/opt/net/wifi/+/ee0920fb68d2f4447936301ce3192c345224e8e7/service/java/com/android/server/wifi/WifiNetworkSelector.java#149

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/201
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/278

FT-SAE is missing in the supplicant configuration verification list,
causing an activation failure when using SAE and the supplicant
supports FT.

Fixes: d17a0a090555 ('supplicant: allow fast transition for WPA-PSK and WPA-EAP')

  $ find * -type f |xargs perl contrib/scripts/spdx.pl
  $ git rm contrib/scripts/spdx.pl

NM didn't support wpa-none for years because kernel drivers used to be
broken. Note that it wasn't even possible to *add* a connection with
wpa-none because it was rejected in nm_settings_add_connection_dbus().
Given that wpa-none is also deprecated in wpa_supplicant and is
considered insecure, drop altogether any reference to it.

Previously we only cared whether supplicant is build with support for
FT. In that case we would pass FT-PSK to supplicant, like

  Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK'

Supplicant would then always try FT with preference, regardless whether
the interface/driver support it. That results in a failure to associate, if
the driver does not support it.

  NetworkManager[1356]: <info>  [1566296144.9940] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK'
  ...
  wpa_supplicant[1348]: wlan0: WPA: AP key_mgmt 0x42 network profile key_mgmt 0x142; available key_mgmt 0x42
  wpa_supplicant[1348]: wlan0: WPA: using KEY_MGMT FT/PSK
  ...
  wpa_supplicant[1348]:   * akm=0xfac04
  ...
  kernel: ERROR @wl_set_key_mgmt :
  kernel: invalid cipher group (1027076)

Since we pass a list of acceptable "key_mgmt" options to supplicant,
FT-PSK should not be used when supplicant knows it's not supported.
That is a supplicant bug.

Regardless, work around it by checking the per-interface capability, and
avoid it if support is apparently not present.

They should be "static" and only visible to this source file.

Also, they should be "const", that allows the linker to place them
into read-only memory.

(cherry picked from commit 722b167953c2384615cb11bbc88988dec7e647ab)

For better or worse, the API does not require the value to be a
UTF-8 string. We cannot just concatenate binary to a string.
Instead, backslash escape it with utf8safe-escape.

Also, this will shut up a (wrong) coverity warning at this place.

(cherry picked from commit 55143dad95dde9e5eae2a5084e39313fcfba4a4a)

We must not just pretend that the value is a NULL terminated string.
That's why we have the length argument.

(cherry picked from commit 9ed26de3daf71020dd0148fcc1ad9de8cc5e5009)