Up until now, a default-route (with prefix length zero) could not
be configured directly. The user could only set ipv4.gateway,
ipv4.never-default, ipv4.route-metric and ipv4.route-table to influence
the setting of the default-route (respectively for IPv6).

That is a problematic limitation. For one, whether a route has prefix
length zero or non-zero does not make a fundamental difference. Also,
it makes it impossible to configure all the routing attributes that one can
configure otherwise for static routes. For example, the default-route could
not be configured as "onlink", could not have a special MTU, nor could it be
placed in a dedicated routing table.

Fix that by lifting the restriction. Note that "ipv4.never-default" does
not apply to /0 manual routes. Likewise, the previous manners of
configuring default-routes ("ipv4.gateway") don't conflict with manual
default-routes.

Server-side this all the pieces are already in place to accept a default-route
as static routes. This was done by earlier commits like 5c299454b49b
('core: rework tracking of gateway/default-route in ip-config').

A long time ago, NMIPRoute would assert that the prefix length is
positive. That was relaxed by commit a2e93f2de4ac ('libnm: allow zero
prefix length for NMIPRoute'), already before 1.0.0. Using libnm from
before 1.0.0 would result in assertion failures.

Note that the default-route-metric-penalty based on connectivity
checking applies to all /0 routes, even these static routes. Be they
added due to DHCP, "ipv4.gateway", "ipv4.routes" or "wireguard.peer-routes".
I wonder whether doing that unconditionally is desirable, and maybe
there should be a way to opt-out/opt-in for the entire profile or even
per-routes.

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

I encountered a failure in the log

    <trace> [1564647990.7822] keyfile: commit: deleting nmmeta file "/etc/NetworkManager/system-connections/35370b0b-e53b-42ea-9fe3-f1b1d552343b.nmmeta" failed
    <trace> [1564647990.7822] keyfile: commit: deleting nmmeta file "/etc/NetworkManager/system-connections/35370b0b-e53b-42ea-9fe3-f1b1d552343b.nmmeta" simulated

I think that was due to SELinux (rh #1738010).

Let nms_keyfile_nmmeta_write() return an errno code so we can log
more information about the failure.

... and nm_utils_fd_get_contents() and nm_utils_file_set_contents().

Don't mix negative errno return value with a GError output. Instead,
return a boolean result indicating success or failure.

Also, optionally

  - output GError

  - set out_errsv to the positive errno (or 0 on success)

Obviously, the return value and the output arguments (contents, length,
out_errsv, error) must all agree in their success/failure result.
That means, you may check any of the return value, out_errsv, error, and
contents to reliably detect failure or success.

Also note that out_errsv gives the positive(!) errno. But you probably
shouldn't care about the distinction and use nm_errno_native() either
way to normalize the value.

nm_utils_file_set_contents() is a re-implementation of g_file_set_contents(),
as such it returned merely a boolean success value.

It's sometimes interesting to get the native error code. Let the function
deviate from glib's original g_file_set_contents() and return the error code
(as negative value) instead.

This requires all callers to change. Also, it's potentially a dangerous
change, as this is easy to miss.

Note that nm_utils_file_get_contents() also returns an errno, and
already deviates from g_file_get_contents() in the same way. This patch
resolves at least the inconsistency with nm_utils_file_get_contents().

The secret-agent D-Bus API knows 4 methods: GetSecrets, SaveSecrets,
DeleteSecrets and CancelGetSecrets. When we cancel a GetSecrets
request, we must issue another CancelGetSecrets to tell the agent
that the request was aborted. This is also true during shutdown.
Well, technically, during shutdown we anyway drop off the bus and
it woudn't matter. In practice, I think we should get this right and
always cancel properly.

To better handle shutdown change the following:

- each request now takes a reference on NMSecretAgent. That means,
  as long as there are pending requests, the instance stays alive.
  The way to get this right during shutdown, is that NMSecretAgent
  registers itself via nm_shutdown_wait_obj_register() and
  NetworkManager is supposed to keep running as long as requests
  are keeping the instance alive.

- now, the 3 regular methods are cancellable (which means: we are
  no longer interested in the result). CancelGetSecrets is not
  cancellable, but it has a short timeout NM_SHUTDOWN_TIMEOUT_MS
  to handle this. We anyway don't really care about the result,
  aside logging and to be sure that the request fully completed.

- this means, a request (NMSecretAgentCallId) can now immediately
  be cancelled and destroyed, both when the request returns and
  when the caller cancels it. The exception is GetSecrets which
  keeps the request alive while waiting for CancelGetSecrets. But
  this is easily handled by unlinking the call-id and pass it on
  to the CancelGetSecrets callback.
  Previously, the NMSecretAgentCallId was only destroyed when
  the D-Bus call returns, even if it was cancelled earlier. That's
  unnecessary complicated.

- previously, D-Bus requests SaveSecrets and DeleteSecrets were not cancellable.
  That is a problem. We need to be able to cancel them in order to shutdown in
  time.

- use GDBusConnection instead of GDBusProxy. As most of the time, GDBusProxy
  provides features we don't use.

- again, don't log direct pointer values, but obfuscate the indentifiers.

I don't like GSList.

This defeats ASLR. Obfuscate the pointers.

In the past, we had a private unix socket. That is long gone.
Drop the remains in "nm-secret-agent.c". The request here really
always comes from the main D-Bus connection.

Maybe the private unix socket makes sense and we might resurrect it one
day. But at that point it would be an entire rewrite and the existing
code is probably not useful either way. Drop it.

They seem useful for debugging. Don't only enable them --with-more-logging.