This is an interface to the Checkpoint/Restore functionality that's
available for quite some time. It runs a command with a checkpoint taken
and rolls back unless success is confirmed before the checkpoint times
out:

  $ nmcli dev checkpoint eth0 -- nmcli dev dis eth0
  Device 'eth0' successfully disconnected.
  Type "Yes" to commit the changes: No
  Checkpoint was removed.

The details about how it's used are documented in nmcli(1) and
nmcli-examples(7).

When the input ends, we indeed eventually want to shut down.

Nevertheless, it might be that we terminated the input *because* we're
already shutting down and want do do our cleanup. Let's not take the
shortcut to nmc_exit() in case the main loop is no longer running.

This doesn't affect existing uses of nmc_readline(), but will be useful
in a future patch.

This makes get_device_list() return an array of NMDevices with a
reference taken and a destroy notifier that unhooks disconnect_state_cb,
so that it could replace the GSList of the same utility used by
disconnect/delete commands.

Suggested-by: Thomas Haller <thaller@redhat.com>

A pointer array is slightly more efficient here, since we don't really
need the ability to insert elements in the middle. In fact, we'd prefer
if we could just add to the end, so that we'd spare some callers from a
need to do a g_slist_reverse().

Even though that alone being a good reason to use a GPtrArray instead of
GSList, I'm doing this for so that I could actually use the returned value
as-is in a call to nm_client_checkpoint_create() in a future patch.

Don't consider "--" a device name. Instead, treat it as a signal to stop
reading the device list.

If a caller expects nothing beyond the device names, it now has to
check.

Prior to this patch, get_device_list() would give the caller no clue
about how many options did it consume. That is okay -- it would always
process all argument until the end, so the no callers would really care.

In a further patch, I'd like to allow termination of the device name
list (with a "--" arguments), so it will be possible to specify further
arguments.

Let's change the protype of this routine to use pointers to argc/argv,
that it will be possible to adjust them.

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

Signed-off-by: Ryosuke Yasuoka <yasuoka0830@gmail.com>

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

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

Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.

To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled

Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled

The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.

The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).

Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.

Co-Authored-By: Thomas Haller <thaller@redhat.com>

For details, read the linked sources.

This requires a new supplicant option, but it seems that supplicant
will silently ignore unrecognized options.

https://bugzilla.redhat.com/show_bug.cgi?id=2072070#c48
https://lists.infradead.org/pipermail/hostap/2022-May/040522.html
https://w1.fi/cgit/hostap/commit/?id=566ce69a8d0e64093309cbde80235aa522fbf84e

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