1) The "enabled-on-global-iface" flag was odd. Instead, have only
and "enabled" flag and skip (by default) endpoints on interface
that have no default route. With the new flag "also-without-default-route",
this can be overruled. So previous "enabled-on-global-default" now is
the same as "enabled", and "enabled" from before behaves now like
"enabled,also-without-default-route".

2) What was also odd, as that the fallback default value for the flags
depends on "/proc/sys/net/mptcp/enabled". There was not one fixed
fallback default, instead the used fallback value was either
"enabled-on-global-iface,subflow" or "disabled".
Usually that is not a problem (e.g. the default value for
"ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case
it is a problem, because the mptcp-flags (for better or worse) encode
different things at the same time.
Consider that the mptcp-flags can also have their default configured in
"NetworkManager.conf", a user who wants to switch the address flags
could previously do:

  [connection.mptcp]
  connection.mptcp-flags=0x32   # enabled-on-global-iface,signal,subflow

but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer
honored. That means, MPTCP handling was always on, even if the sysctl was
disabled. Now, "enabled" means that it's only enabled if the sysctl
is enabled too. Now the user could write to "NetworkManager.conf"

  [connection.mptcp]
  connection.mptcp-flags=0x32   # enabled,signal,subflow

and MPTCP handling would still be disabled unless the sysctl
is enabled.

There is now also a new flag "also-without-sysctl", so if you want
to really enable MPTCP handling regardless of the sysctl, you can.
The point of that might be, that we still can configure endpoints,
even if kernel won't do anything with them. Then you could just flip
the sysctl, and it would start working (as NetworkManager configured
the endpoints already).

Fixes: eb083eece5a2 ('all: add NMMptcpFlags and connection.mptcp-flags property')
(cherry picked from commit c00873e08f4d0bc4a3f0b8a93beb793fcab78afa)

(cherry picked from commit 0e26203e02969ce6e4475ea3bb2acfcdafed1a37)

There is still no agreement, about how to name this option, or whether
it should exist at all. Revert the addition of the flag.

As the new release is coming up, drop the new API.

https://bugzilla.redhat.com/show_bug.cgi?id=2072070#c64
https://bugzilla.redhat.com/show_bug.cgi?id=2077973#c24
http://lists.infradead.org/pipermail/hostap/2022-July/040665.html

This reverts commit a5a4aea2e627214a3da3c6fdb2651d65a7182ea8.

The default behavior might be sufficient. Drop those flags for now,
and figure out a good solution when we have an actual use-case.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/455

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1325

Fixes: 9d2290135ce5 ('cli: make nmcli do its own command completion')

It's happier there. No change in behavior.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1317

The reproducer for another problem tripped an assertion failure:

  $ nmcli con del act-conn
  Connection 'act-conn' (...) successfully deleted.
  $ nmcli con down another-conn

  (process:94552): nm-CRITICAL **: 17:07:21.170: ((src/libnm-client-impl/nm-remote-connection.c:593)): assertion '<dropped>' failed
  Connection 'another-conn' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4)
  $

What happens is that the second invocation, when resolving the
connection name into a NMRemoteConnection object, assumes an active
connection has a settings connection.

This assumption is likely to be wrong immediately after deleting a
connection was active, before giving the active connection enough time
to fully deactivate.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1317

This commit moves the `nm_vpn_wireguard_import()` function
implementation from `libnmc-base` to `libnm-client-impl`, renaming it to
`nm_conn_wireguard_import()`.

A new `nm_conn_utils` header file is added in `libnm-client-public`.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1031

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1299