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

This is also what nm_keyfile_plugin_kf_get_int64() does. It's useful to
know whether a value was missing or invalid.

Also, mark 1.20 as stable.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/224

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().

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/231