This makes it possible to retain Internet connectivity when multiple devices
have a default route, but one with the link type of a higher priority can not
reach the Internet.

This moves tracking of connectivity to NMDevice and makes the NMManager
negotiate the best of known connectivity states of devices. The NMConnectivity
singleton handles its own configuration and scheduling of the permission
checks, but otherwise greatly simplifies it.

This will be useful to determine correct metrics for multiple default routes
depending on actual internet connectivity.

The per-device connection checks is not yet exposed on the D-Bus, since they
probably should be per-address-family as well.

Fixes test on Fedora/i686.

It turns out that some routers return responses to DHCP6
Information-request messages that do not contain any of the options
that we insert in the "options" table. When that happened and the
info-only flag for DHCP6 was set, the assertion was triggered and
NetworkManager crashed. We remove the assertion as having empty options
is a possibility and is harmless anyway. This happened while using the
internal dhclient.

Autoconnect slaves based on device name order instead of activation
timestamp.

Perform the lookup for a matching device earlier, so that in
autoconnect_slaves() we already know which device a connection is
being activated on. This will be needed to sort the returned
connections by interface name.

Add a @unavailable_devices argument that specifies an hash table of
devices to be excluded from the search.

We should try to guarantee a stable activation order of connections
across reboots; this is required, for example, for bonds because they
get assigned the MAC address of the first device enslaved, and thus
changing the activation order of slaves means also changing the MAC
address of the bond. Since we activate connections in the order links
are discovered, having a stable sorting of links returned by platform
is enough.

The ifindex of interfaces can change between reboots as it depends on
the order in which kernel discover interfaces. Provided that the
system uses a mechanism to enforce persistent interface naming (as
udev rules or systemd-udevd predictable names), and that NM starts
after all interfaces have been announced by udev, using the interface
name instead of ifindex will guarantee a consistent order.

When slave connections are autoactivated as dependency to master we
don't check if a compatible device is available before trying to
activate them, leading to the following failed assertion:

 nm_act_request_new: assertion 'NM_IS_DEVICE (device)' failed