[th/addr-gen-mode-to-dbus] libnm: avoid serializing "ipv6.addr-gen-mode" default to D-Bus

When serializing setting properties to GVariant/D-Bus, we usually omit values that are set to the default. That is done by libnm(-core), so it happens both on the daemon and client side. That might be useful to avoid a large number of properties on D-Bus.

Before changing the default value for "ipv6.addr-gen-mode" ([1]), we would not serialize the previous default value ("stable-privacy"). Now we would serialize the new default value ("default). This change causes problems.

Scenario 1: have a profile in the daemon with "ipv6.addr-gen-mode=stable-privacy", have an older daemon version before [1] and a newer client after [1]. Result:

The daemon exposes the profile on D-Bus without the addr-gen-mode field (because it's the default). To the client, that is interpreted differently, as "ipv6.addr-gen-mode=default". This is already somewhat a problem. More severe is when modifying the profile, the client would now serialize the value "default" on D-Bus, which the older daemon rejects as invalid. That means, you could not modify the profile, unless also resetting addr-gen-mode to "stable-privacy" or "eui64".

You can imagine other scenarios where either the daemon or the client is before/after change [1] and the addr-gen-mode is set to either "default" or "stable-privacy". Depending on what scenario you look, that can either be good or bad.

Scenario 1 is pretty bad, because it means dnf upgrade NetworkManager && nmcli connection modify ... will fail (if the daemon was not restated). So try to fix Scenario 1, by also not serializing the new default value on D-Bus. Of course, some of the scenarios will get different problems, like having a misunderstanding about what value is actually set. But those problems are likely less severe.

In case both client and daemon are older/newer than [1], it doesn't matter either way. The problem happens with different version and is caused by a change of the default value.

[1] e6a33c04