wifi: don't query nl80211 for non-WiFi devices (bgo #740131)

The upstream kernel added module aliases for nl80211 in commit
fb4e156886ce6e8309e912d8b370d192330d19d3, so querying nl80211
now auto-loads the module.  Previously NM was doing this to
determine whether an ethernet-like device was a Wi-Fi device
that supported nl80211, but this leads to the nl80211 loading
on platforms that will never have or use Wi-Fi.

Since every nl80211-capable device will already have
DEVTYPE=wlan set (from /sys/class/net/wlan0/uevent), we can use
that as an indicator that the ethernet-like device is WiFi
instead of asking nl80211.

https://bugzilla.gnome.org/show_bug.cgi?id=740131
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147)

For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which
caused the DHCP client to exit early because it had no local address
to bind to.

https://bugzilla.gnome.org/show_bug.cgi?id=740147
core: bounce disable_ipv6 when setting userspace IPv6 link-local (bgo #740096)

The kernel does not terminate an ongoing IPv6LL address process when
the IPv6LL address generation mode is set to 'none' (indicating that
userspace wishes to handle IPv6LL).  Next, NetworkManager does not
expose IPv6 addresses internally until they have completed DAD.  This
means that the kernel may still be performing DAD for an IPv6LL
address when NetworkManager turns userspace IPv6LL on, and when
DAD is complete NetworkManager will finally pay attention to the
address.  If the device is in the DISCONNECTED state, NetworkManager
will then generate and assume an IPv6LL-only connection on the device.

Unfortunately, that behavior happens if the following is true:

1) IPv6LL addressing takes a while (eg, dad_transmits is high or
the kernel takes a while for some reason)

2) the activated connection fails quickly (dhclient fails or some
other fatal error terminates the activation attempt)

3) the activated connection has ipv6.method=ignore

In this case, when the device was brought up and ipv6.method=ignore,
NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl
properties.  The kernel then generated an IPv6LL address and began
DAD.  dhclient failed quickly, and NM deactivated the device.  NM
then turned off kernel IPv6LL when deactivating the device, but the
kernel does not terminate the ongoing DAD.  Some time after the device
entered the DISCONNECTED state, the kernel finished DAD and that
allowed NetworkManager to internally see the address, which caused
NetworkManager to emit the 'recheck-assume' signal.  This
generated a new IPv6LL-only connection which was then assumed.

Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during
device deactivation flushes the tentative kernel IPv6LL address,
thus preventing the address from being announced after userspace
IPv6LL is re-enabled.  The other alternative is to expose
tentative addresses (eg those still doing DAD) in NMPlatform so
they would be flushed when the device deactivates, but that is a
larger & riskier set of changes.

Reproducer:
- ifconfig eth0 down
- prepare a DHCPv4 connection with ipv6.method=ignore
- set /proc/sys/net/ipv6/conf/all/dad_transmits to "15"
- ensure that DHCPv4 will fail (replace dhclient with a script
    that exits after 2 seconds or something)
- run NetworkManager
- activate the DHCP connection and watch it immediately fail
- wait for the kernel to announce the IPv6LL address after DAD finishes
- watch NM "assume" the new IPv6LL connection

https://bugzilla.gnome.org/show_bug.cgi?id=740096
trivial: remove leftover NM_IFACE_HELPER references

Left over from a previous version of the iface helper patches and was
never removed when NM_IFACE_HELPER was removed.  Since NM_IFACE_HELPER
wasn't defined, this code was already always compiled.
device: Remove unmanaged slaves from master when they disappear

We've previously been just watching for state changes into UNMANAGED state. No
state change is emitted upon removal of a device which is already unmanaged.

We ought to always emit the device removed signal if the device disappears,
watch for it being emmitted for slaves and react appropriately.
device: Don't consider device with only LL address configured

LXC domains are given a veth interface that's up and has a LL address
upon their creation.
device,settings: don't assume the device is connected because it's software

It was possibly done to prevent NM from fiddling with the interface. However,
assuming a connection completely prevents the user from being able to use
their conneciton.

Let's just not add default connection to software devices.
Revert "core: make veth devices default-unmanaged for now"

veth devices being default unmanages makes it impossible to configure the
connectivity by NM on container bootup. Now that we don't add a default
connection when a veth is discovered is shouldn't be necessary to prevent
management anymore.

This reverts commit ebeaeaed4d3180c27cc059fe0ff199153fa9ec24.
cli: Watch for device as well as AC state changes when activating

The signals might be delivered in no particular order and we need to wait for
the device to reach stable state (whether it's successfully conntected or not)
as well as the active connection to leave ACTIVATING state.
Merge branches 'lr/device-activation' and 'lr/veth-managed', remote-tracking branches 'fd/lr/ipv6-tokens', 'fd/lr/nm-1-0-fixes' and 'fd/lr/unmanaged-slaves' into integration