nm_setting_diff() ends up calling the compare_fcn() hook. Previously,
the hook for "dns" was _nm_setting_property_compare_fcn_default()
and the hook for "dns-data" was _nm_setting_property_compare_fcn_ignore().

That's wrong. _nm_setting_property_compare_fcn_default() converts
the property to D-Bus and compares the GVariant. However, "dns" has
to_dbus_only_in_manager_process set, so it wouldn't

Fixes: 63eaf168d1b8 ('libnm: add "dns-data" replacement for "ipv[46].dns" properties on D-Bus')

Just gives a better failure message. These checks fail often, when new
code gets added.

- nm_setting_ip_config_add_dns() and nm_setting_ip_config_remove_dns_by_value()
  used to assert that the provided input is valid. That is not
  documented and highly problematic.
  Our parsing code for keyfile, ifcfg-rh and GVariant rightly just call
  add. Likewise, nmcli. We cannot reasonably expect them to pre-validate
  the input. Why would we anyway?
  This is wrong in particular because we usually want the user to be
  able to construct invalid settings. That is often necessary, because
  whether a value is valid depends on other values. So in general, we
  can only validate when all properties are set. We have
  nm_connection_verify() for that, and asserting/validating during add
  is very wrong. Note that "add" still filters out duplicates, which
  may be an inconsistency, but well.
  Also, the user could set any bogus value via the NM_SETTING_IP_CONFIG_DNS
  property. Those should be allowed to be removed, and the same values
  should be allowed to be added via the add method.

- add() does a normalization, presumably so that the values look nice.
  Do the same normalization also when using the NM_SETTING_IP_CONFIG_DNS
  property setter.

- previously, the setter could also set unnormalized values. As
  nm_setting_ip_config_remove_dns_by_value() looked for the normalized
  value, you couldn't remove such values anymore. That is fixed now,
  by letting the property setter do the same normalization.

- don't allocate a GPtrArray unless we need it. No need for the extra
  allocation.

- in the property setter, first set the new value before destroying the
  previous GPtrArray. It might not be possible, but it's not clear to me
  whether the strv argument from the GValue is always deep-copied or
  whether it could contain strings to the DNS property itself.

This helper returns a pointer (to a thread local variable).

When you call

  nm_uuid_generate_from_strings_strv(uuid_type, type_arg, v1, v2);

you'd probably expect that both values are honored in some way.
However, if v1 happened to be NULL, then previously v2 would be ignored.

Extend nm_uuid_generate_from_strings() to accept also NULL values and
pass on the length. Currently, there are no users of nm_uuid_generate_from_strings(),
so nobody is affected by this change.

Also extend nm_uuid_generate_from_strings_strv() to take a length
argument. It still accepts "-1" to take the input strv as a NULL
terminated array.

If a positive length is provided to nm_uuid_generate_from_strings_strv(),
it hashes the same UUID as the respective NULL terminated array. But of
course only, if there is no NULL inside the array. If there are any
NULLs, a distinct UUID gets generated.

NMConnection is an interface, implemented by NMSimpleConnection and
NMRemoteConnection.

For the most part, an NMConnection is only the content of the profile
(the settings). The "path" of the connection refers to the D-Bus path,
and wouldn't really make sense of the NMConnection interface or the
NMSimpleConnection type.

As such, the daemon (which only uses NMConnection and
NMSimpleConnection) never sets the path. Only libnm does.

NMClient uses NMRefString extensively for the D-Bus interface and the
path is already internalized. Take advantage of that. It is very likely,
that we are able to share the path instance in libnm at which point it
makes sense to use NMRefString.

Also, during nm_simple_connection_new_clone(), we can just take another
reference instead of cloning the string.

For new uses of nm_uuid_generate_from_strings() we should generate version5
UUIDs and we should use unique namespace UUID arguments.

The namespace UUID was so far replaced by always passing a special prefix
as first string. It seems nicer to use a namespace instead.

Version3 UUIDs should not be used for new applications.

Hence, nm_uuid_generate_from_strings_v3() is no longer a desirable way to
generate UUIDs, so drop the wrapper.