policy: allow non-local admin sessions to control the network (rh #1145646)
bluez: fix compiler error due to redefinition of typedef

clang warns:
    make[5]: Entering directory `./NetworkManager/src/devices/bluetooth'
      CC       nm-bluez5-dun.lo
    nm-bluez5-dun.c:50:3: error: redefinition of typedef 'NMBluez5DunContext' is a C11 feature [-Werror,-Wtypedef-redefinition]
    } NMBluez5DunContext;
      ^
    ./nm-bluez5-dun.h:27:36: note: previous definition is here
    typedef struct _NMBluez5DunContext NMBluez5DunContext;
                                       ^

Fixes: f1c9595311f52d8b79e8d2032e006005613a8fb1
Signed-off-by: Thomas Haller <thaller@redhat.com>
build: ensure rl_echo_signal_char() exists in the readline library
keyfile: fix handling of enum/flags properties after fcfb4b40 (bgo #738585)

When some properties got converted to G_TYPE_ENUM and G_TYPE_FLAGS
the keyfile plugin was not updated to handle these types.

https://bugzilla.gnome.org/show_bug.cgi?id=738585
trivial: add missing break
remote-settings: Mark service as running when using private bus

When using a private bus connection, the service is never marked
as running when settings are initialized asynchronously. Successfully
opening a socket in NM's runtime directory should already imply
a running service, so just mark it as such (as we already do in
the synchronous path).
core: don't override external route metrics (bgo #738268)

A generated connection contains a copy of the device's existing
configuration, so it's entirely redundant to merge the connection
back into the device's IP config.  But even though that should
result in no changes to the IP config, NMSettingIPxConfig treats a
route metric of '0' as the device priority, while NMIPxConfig
allows 0 as a valid route metric.  Since the setting values
are preferred (they are supposed to be user-supplied and thus
override anythign else, but in this case they are generated and
thus not user-supplied) external routes with a metric of 0 are
overwritten with the device priority metric.

https://bugzilla.gnome.org/show_bug.cgi?id=738268
core: remove child devices without deconfiguring them (bgo #738479)

When a child device is found and an IP configuration already exists
for it even though it is under NM control (like when pppd applies
IP config to a WWAN device before NM gets the IP details from the pppd
plugin), don't deconfigure the child device when removing it from the
device list, because this breaks the device's configuration.

https://bugzilla.gnome.org/show_bug.cgi?id=738479
core: ensure interface is up before applying IP configuration (bgo #738479)

Routing configuration fails to apply if the device is not IFF_UP, so if
we're going to apply IP configuration to the device, make sure it's IFF_UP
first.

https://bugzilla.gnome.org/show_bug.cgi?id=738479
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