device: Don't enslave unmanaged devices

They don't notify of their removal as they don't transition to UNMANAGED
state in remove_device() and thus leave hanging in bridges despite the
actual device is gone. It's probably a good idea to ignore them altogether.
libnm: Drop a wrong assert

An active connection object could disappear from the bus before its removal
from NMManager:active-connections is signalled -- don't assert it's gone from
there already.

Here /o/fd/NM/ActiveConnection/81 disappears shortly after it's added:

libnm-Message: PC: (0x9ebd088) NMManager:active-connections => '['/org/freedesktop/NetworkManager/ActiveConnection/81', '/org/freedesktop/NetworkManager/ActiveConnection/80']' (ao / NMActiveConnection)
libnm-Message: PC: (0x9ebd088) NMManager:activating-connection => ''/'' (o / NMActiveConnection)
libnm-Message: PC: (0x9ed1458) NMDeviceTeam:state => '110' (u)
libnm-Message: PC: (0x9ed1458) NMDeviceTeam:state-reason => '(110, 0)' ((uu))
libnm-Message: PC: (0x9ece9a0) NMActiveConnection:state => '3' (u)
libnm-Message: PC: (0x9ebd088) NMManager:state => '20' (u)
libnm-Message: PC: (0x9ebd088) NMManager:devices => '['/org/freedesktop/NetworkManager/Devices/0', '/org/freedesktop/NetworkManager/Devices/2', '/org/freedesktop/NetworkManager/Devices/3']' (ao / NMDevice)
libnm-Message: PC: (0x9ebd088) NMManager:active-connections => '['/org/freedesktop/NetworkManager/ActiveConnection/81', '/org/freedesktop/NetworkManager/ActiveConnection/80']' (ao / NMActiveConnection)
libnm-Message: PC: (0x9ece9a0) NMActiveConnection:state => '4' (u)
libnm-Message: PC: (0x9ece9a0) NMActiveConnection:devices => '[]' (ao / NMDevice)
libnm-Message: Could not create object for /org/freedesktop/NetworkManager/ActiveConnection/81: Method "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist

(process:18042): libnm-CRITICAL **: object_creation_failed: assertion 'find_active_connection_by_path (self, failed_path) == NULL' failed
libnm: Complete activation when ActiveConnection abruptly disappears

A NMActiveConnection may disappear before a match with NMDevice is found. In
such case recheck_pending_activations() would never call the activation
callback and the client would hang indefinitely:

libnm-Message: PC: (0x95bf088) NMManager:active-connections => '['/org/freedesktop/NetworkManager/ActiveConnection/225']' (ao / NMActiveConnection)
libnm-Message: PC: (0x95bf088) NMManager:activating-connection => ''/'' (o / NMActiveConnection)
libnm-Message: PC: (0x95d0a28) NMActiveConnection:state => '4' (u)
libnm-Message: PC: (0x95d0a28) NMActiveConnection:devices => '[]' (ao / NMDevice)
libnm-Message: PC: (0x95bf088) NMManager:active-connections => '[]' (ao / NMActiveConnection)
*hang*

Let's listen for active-connection-removed and tear down the activation with
an error if the removed connection is one we're activating.
connections: Don't give up if we've not seen an active connection yet

It will appear later on.

https://bugzilla.redhat.com/show_bug.cgi?id=1149200
team: Don't let teamd rip off the link when it terminates

We might be reactivating a connection on the device and don't want it to go
away. In other cases we still take care of the link deletion ourselves.
device:  Don't delete the link if a re-activation is scheduled
core: fix IP4Config.RouteData and IP6Config.RouteData

NMIP4Config/NMIP6Config have their own NMIPRoute->D-Bus conversion
code since the code in libnm-core is gdbus-specific. But they were
doing it wrong, resulting in clients seeing a next hop of 0.0.0.0/::
for all routes.
Merge remote-tracking branches 'lr/lr-unmanaged-slaves', 'fd/lr/ipv6-tokens' and 'fd/lr/team-activation' into integration