network: use the OpenConnect authentication dialog

[schmidma]

Description

NetworkManager's OpenConnect plugin needs more than a generic username and password for many AnyConnect connections. Authentication can involve multiple forms, and the plugin expects an authentication cookie together with gateway, certificate, and resolution metadata.

Use the standard nm-openconnect-auth-dialog for eligible AnyConnect password profiles. This gives DMS and external nmcli activations the same authentication path and uses the helper's existing Secret Service integration for saved passwords.

DMS prepares profiles with NetworkManager's not-saved flags before activation. Runtime cookies and gateway handoff values remain ephemeral. Safe helper preferences are written back only after the matching VPN activation succeeds, using a version-guarded full-profile update that preserves unrelated settings and stored secrets.

Authentication attempts are scoped to the active NetworkManager connection. Concurrent requests share one helper, while cancellation, REQUEST_NEW, disconnects, timeouts, and stale signals cannot reuse or persist an old result.

Existing behavior remains in place for:

• Fortinet password and browser authentication
• GlobalProtect SAML authentication
• certificate, PKCS#11, token, and browser-based AnyConnect profiles

The shared OpenConnect path also preserves RESOLVE handoff data, avoids stale legacy cookie reuse, and prevents GlobalProtect authentication output from exposing cookies in logs.

Profiles missing the required transient-secret flags can be prepared by connecting once through DMS before using external activation tools.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that changes existing behavior)
• Refactor / internal cleanup
• Documentation
• Other

Related issues

None.

Screenshots / video

Not included. Authentication uses the standard OpenConnect dialog provided by the installed NetworkManager plugin.

Checklist

• My code follows the conventions in CONTRIBUTING.md
• I have tested my changes locally
• New user-facing strings are wrapped in I18n.tr() with translator context, reusing existing terms where possible
  • No new QML strings or translation terms.
• Go changes: ran make fmt, added/updated tests, make test passes, and go mod tidy is clean
• QML changes: ran make lint-qml with no new warnings
  • No QML changes.
• I have opened a corresponding pull request in dlx-docs to document any new behaviors
  • Documentation is deferred for this draft.

Additional validation included race tests for the NetworkManager and BlueZ packages, an isolated NetworkManager integration harness with private buses and namespaces, and a live AnyConnect connection and keyring-backed reconnect through nmcli.