This is the version shipped in Fedora 37. As Fedora 37 is now out, the
core developers switch to it. Our gitlab-ci will also use that as base
image for the check-{patch.tree} tests and to generate the pages. There
is a need that everybody agrees on which clang-format version to use,
and that version should be the one of the currently used Fedora release.

Also update the used Fedora image in "contrib/scripts/nm-code-format-container.sh"
script.

The gitlab-ci still needs update in the following commit. The change
in isolation will break the "check-tree" test.

For convenience, allow also to match the UUID by prefix -- if the
"uuid" selector is used.

Note that still, there must be only one candidate found. The "uuid"
selector guarantees to find a unique connection.

  $ nmcli -f connection.uuid,connection.id connection show uuid eb43d80c

The "connection.uuid" and the D-Bus path are supposed to be unique on
D-Bus. Anything else indicates to a bug somewhere.

Still, with `nmcli connection $operation [uuid|path] $arg ...` ensure
that the result is always unique.

In practice, this should make no difference. In the case of an
unexpected duplicate, it seems better to fail and uphold the
guarantee that these selectors give unique results.

Also, next we will accept matching prefixes of the UUID. While partial
match will then be supported, it should still be unique. That is, the
"uuid" specifier should always only yield one result. While this patch
should make not difference in practice today (albeit enforcing something
that should be valid), it will make a difference then.

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

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 adds a global "--offline" option and allows its use with "add" and
"modify" commands. The "add" looks like this:

  $ nmcli --offline conn add type ethernet ens3 ipv4.dns 192.168.1.1 \
      >output.nmconnection

The "modify" is essentially implementing what's been suggested by
Beniamino in bugzilla ticked (referred to below):

  $ nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 \
      <input.nmconnection >output.nmconnection

Other commands don't support the argument at the moment:

  $ nmcli --offline c up ens3
  Error: 'up' command doesn't support --offline mode.

https://bugzilla.redhat.com/show_bug.cgi?id=1361145

We often create the source with default priority, no destroy function and
attach it to the default context (g_main_context_default()). For that
case, we have wrapper functions like nm_g_timeout_add_source()
and nm_g_idle_add_source(). Use those.

There should be no change in behavior.

We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.

So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.

As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).

The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as

  Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)

[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format