[RFC] dbus: expose per-BSS security capabilities

Hi,

NetworkManager cannot currently distinguish WPA2-Personal, WPA3-Personal,
and WPA2/WPA3 transition networks when using its iwd backend.

iwd has the required information internally.  scan_bss stores the WPA and
RSN information elements, and scan_bss_get_rsn_info() exposes the parsed AKM
and cipher information.  However, the stable D-Bus API reduces all of these
personal network variants to Network.Type="psk".  BasicServiceSet currently
exports only Address.

This causes a concrete integration failure.  NetworkManager maps an iwd
Network with Type="psk" to NM_802_11_AP_SEC_KEY_MGMT_PSK.  A saved NM profile
with 802-11-wireless-security.key-mgmt="sae" then fails the normal AP/profile
compatibility check and is removed from Device.AvailableConnections, even
while iwd is successfully connected to the same network using SAE.

Observed with NetworkManager 1.56.1 and iwd 3.12 on a WPA2/WPA3 transition
network:

  NM profile key-mgmt:       sae
  iwd negotiated security:  WPA3-Personal + FT
  NM AP RsnFlags:           0x188 (CCMP + PSK, no SAE)
  NM AvailableConnections:  empty

Would it be acceptable to extend net.connman.iwd.BasicServiceSet with stable
WPA/RSN security capability information?

The information needs to include at least:

  - advertised AKM suites (PSK, FT-PSK, SAE, FT-SAE, and so on)
  - pairwise and group ciphers
  - management frame protection capability and requirement

Per-BSS properties seem preferable to a Network-level value because BSSs in
the same ESS may advertise different capabilities.  A consumer such as
NetworkManager can aggregate the capabilities when presenting the iwd
Network as one logical AP while leaving BSS selection and roaming to iwd.

One possible API shape would be an extensible read-only RSN dictionary on
BasicServiceSet, similar to:

  RSN = {
      "KeyManagement": ["psk", "sae", "ft-sae"],
      "Pairwise": ["ccmp"],
      "Group": "ccmp",
      "ManagementFrameProtection": "optional"
  }

The exact representation is the main subject of this RFC.  Raw suite
selectors, separate properties, or an aggregate Network property may fit
iwd's API conventions better.

A corresponding NetworkManager change would consume these capabilities
instead of synthesizing PSK-only RsnFlags from Network.Type.  Separately, NM
should preserve an SAE-only profile policy in the generated iwd profile by
using:

  [Settings]
  TransitionDisable=true
  DisabledTransitionModes=personal

Related reports and downstream investigation:

  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1489
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1693
  https://invent.kde.org/plasma/plasma-nm/-/merge_requests/571

There was prior discussion indicating that additional BasicServiceSet
properties are welcome when the data already exists in scan_bss:

  https://lore.kernel.org/iwd/[email protected]/

If this direction is acceptable, I can follow up with the D-Bus
documentation, implementation, and tests after agreeing on the property
format.

Regards,
Aleks