gitignore: ignore dhcp test binary

Signed-off-by: Thomas Haller <thaller@redhat.com>
dhcp: fix swapped order of argument for logging function

Signed-off-by: Thomas Haller <thaller@redhat.com>
dhcp/test: fix compiler warning about pointer arithmetric for void*

clang warns:

    make[4]: Entering directory `./NetworkManager/src/dhcp-manager/tests'
      CC       test-dhcp-utils.o
    test-dhcp-utils.c:684:2: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wpointer-arith]
            COMPARE_ID (nothex, TRUE, nothex, strlen (nothex));
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    test-dhcp-utils.c:667:23: note: expanded from macro 'COMPARE_ID'
                    g_assert (memcmp (p + 1, expected, expected_len) == 0); \
                                      ~ ^

Signed-off-by: Thomas Haller <thaller@redhat.com>
vpn: fix cleanup of connection timeout in maybe_complete()

Fixes: a966a5e8b5c0b62975833b12bbb67d7e87f307ce
Signed-off-by: Thomas Haller <thaller@redhat.com>
libnm-core: fix NMSetting property override docs

The docs for _nm_setting_class_add_dbus_only_property() and
_nm_setting_class_override_property() mistakenly still referred to
some functionality that didn't make it into the final version, and
also had only been partially updated for the GValue->GVariant change.
libnm-core: tweak handling of overridden properties

nm_setting_compare() and nm_setting_diff() were ignoring the get_func
of overridden properties, because that function requires passing an
NMConnection, and they didn't have one to pass. This wasn't a problem
yet because the only user of _nm_setting_class_override_property()
wasn't using a get_func anyway, but it would cause problems later.

The connection arg to NMSettingPropertyGetFunc is really there to be
used by D-Bus-only properties (which don't get compared anyway), not
for ordinary property overrides. So split it into two different
function types: NMSettingPropertySynthFunc (used by D-Bus-only
properties, to synthesize a fake property value for D-Bus, possibly
using other properties in the NMConnection), and
NMSettingPropertyGetFunc (used by overridden properties for both D-Bus
and comparison purposes, and not getting an NMConnection argument).
libnm-core, all: merge IPv4 and IPv6 address/route types

Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
libnm-core: add NMIPAddress/NMIPRoute attributes, use for labels

Add key-value attributes to NMIPAddress and NMIPRoute, and use them to
store IPv4 address labels. Demote NMSettingIP4Config:address-labels to
a D-Bus-only property, and arrange for :addresses setter to read the
labels out of that property when creating the addresses.
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes

Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.

Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
core, clients: implement dhcp-send-hostname for IPv6

Now that NMSettingIP6Config inherits the dhcp-send-hostname property
from NMSettingIPConfig, fix things up so that it actually gets used.

(Note that this changes behavior: previously if ip6.dhcp-hostname was
unset, no hostname would be sent. Now, the system hostname will be
set. Also, ifcfg-rh does not currently support this property, so there
is no way to disable this...)
all: stop pretending to support multiple "gateway"s

NMSettingIP[46]Config let you associate a gateway with each address,
and the writable settings backends record that information. But it
never actually gets used: NMIP4Config and NMIP6Config only ever use
the first gateway, and completely ignore any others. (And in the
common usage of the term, an interface can only have one gateway
anyway.)

So, stop pretending that multiple gateways are meaningful; don't
serialize or deserialize gateways other than the first in the
'addresses' properties, and don't read or write multiple gateway
values either.
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway

The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.

Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.

Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
libnm-core, libnm, core: add AddressData and RouteData properties

Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.

This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.

NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.

The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
libnm-core: don't warn about unrecognized properties

b64c82a3 removed the warning in libnm-util when
nm_setting_new_from_hash() sees an unrecognized property, but we were
still warning in the equivalent libnm-core code. But it doesn't make
sense to warn here either: we do add new properties sometimes, but we
always make sure that older clients still get the information they
need as well, so they can just ignore the new property.
libnm: create NMIPConfig as parent of NMIP4Config and NMIP6Config

Create NMIPConfig as the parent of NMIP4Config and NMIP6Config, and
remove the two subclasses from the public API; while it's convenient
to still have both internally, they are now identical to the outside
world.
libnm: create NMDhcpConfig as parent of NMDhcp4Config and NMDhcp6Config

As with NMIP4Config and NMIP6Config, merge the two DHCP config classes
into one in the public API.
libnm-core: don't serialize empty address-labels

If no address in an NMSettingIP4Config has a label, then don't bother
serializing an array of empty strings.
all: allow route metrics to be "0"

Change NMIPRoute to use "-1" for "default", so that "0" is a valid
metric. Update everything for that.
all: reorganize IP address/gateway/route properties
dhcp: fix building without sys/auxv.h