tui: clarify the "Device" widget with PPPoE connections (rh #1105753)

PPPoE connections involve two different network connections, making it
ambiguous what the "Device" field refers to. Clarify that it refers to
the Ethernet device, not the PPP device.
cli: fix 'nmcli connection up bond0' being stuck

It can happen on activating a master without slaves. Active connection will
not move past activating state.
libnm: further NULL-vs-empty-array fixes

In some cases, code may look at the value of an array-valued property
during object initialization, before NMObject has set it to its actual
initial value. So ensure that we initialize all such properties to an
empty array, rather than leaving them NULL.

Also fix another bug in NMClient that could result in
priv->active_connections being NULL during certain signal emissions,
and fix nm_client_get_active_connections() to not return NULL when NM
was not running.
libnm: fix async property circular reference handling

3e5b3833 changed various libnm methods to return 0-length arrays
rather than NULL, and changed various other places to assume this
behavior. The guarantee that they didn't return NULL relied on the
assumption that all D-Bus properties would get initialized by NMObject
code before anyone could call their get methods.

However, this assumption was violated in the case where two objects
circularly referenced each other (eg, NMDevice and
NMActiveConnection). f9f9d297 attempted to fix this by slightly
changing the ordering of NMObjectCache operations, but it actually
ended up breaking things and causing infinite loops of object creation
in some cases.

There's no way to guarantee we never return partially-initialized
objects without heavily rewriting the object-creation code, so this
reverts most of f9f9d297 (leaving only the new comment in
_nm_object_create()). The crashes introduced by 3e5b3833 will no
longer happen because we've now fixed the classes to have initialized
their object arrays to non-NULL values even before they get the real
values.
libnm: add -added and -removed signals for ACs to NMManager
libnm: postpone activation callback until all objects are ready

In some cases, the nm_client_activate_connection() callback could be
invoked when either the NMActiveConnection or the NMDevice had not
been initialized yet. Fix it to wait for both of them to be fully
initialized before invoking the callback.
core: lie about NMActiveConnection:state in new connections

NMActiveConnections start out in state "unknown", but then quickly
switch to "activating". Unfortunately, it's sometimes possible for
this to be externally visible. Fix this by lying and saying that state
is "activating" during the initial "unknown" stage (though not if the
state changes to "unknown" later on).

(Actually changing the initial state to "activating" breaks things
because some code depends on there being a transition into the
"activating" state.)
libnm: abstract out duplicated device-creating code in tests
tools: add a bit more activation support to test-networkmanager-service.py

Now test-networkmanager-service.py can create ActiveConnections, though
they don't actually finish activating.
libnm: add an active-connection test to test-nm-client

Test NMClient's handling of active connections, and in particular test
that we can correctly resolve the circular reference between an
NMDevice and an NMActiveConnection, both synchronously and
asynchronously.
tools: add a bit of support for VLANs to test-networkmanager-service.py
libnm: add a virtual device creation-and-activation test

Add a test of creating a (virtual) device and activating a connection
on it at the same time.
libnm: add an object-creation-failed test
libnm, core: fix problems with device activation (bgo 737993)
connections: Listen on NMDevice::state-changed instead of notify::state

We need to be sure that NMDevice's properties are already up to date, as we're
accessing the active_connection from withing the signal handler.

https://bugzilla.redhat.com/show_bug.cgi?id=1149200
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
connections: The active connection state might already have progressed

Trigger the signal handler once when we hook it.

https://bugzilla.redhat.com/show_bug.cgi?id=1149200
Merge remote-tracking branches 'lr/lr-unmanaged-slaves', 'lr/lr-ipv6-tokens', 'lr/lr-ap', 'lr/lr-rdisc-mtu', 'lr/lr-rpm-build', 'lr/lr-lxc', 'lr/lr-hostname' and 'lr/lr-bond-activation' into integration