platform: add typedef for unions NMPlatformIPXAddress and NMPlatformIPXRoute

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: refactor NMDefaultRouteManager to use union type NMPlatformIPXRoute

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: minor fix when having multiple default routes with metric MAXUINT32

The case of having a metric MAXUINT32 is special, because in face of
multiple default routes with the same metric, NMDefaultRouteManager
cannot reduce the effective metric (because there is no lower priority
value).

This case works already correct, just when adding such a default route,
ensure that we add it to the *first* entry.

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: remove unused @do_sync argument from NMDefaultRouteManager functions

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: remove redundant remove_default_route() functions from NMDefaultRouteManager

When calling update_default_route(), NMDefaultRouteManager will look at the
source, and determine whether it has a default route or not. For example
for device sources, this means calling nm_device_get_ip4_default_route().

If the source indicates that it has no default route, the effect of
calling update_default_route() is the same as calling
remove_default_route() (hence, remove() can be replaced by update()).

If the source however still indicates a default route, the behavior
would be different. This case would be an undesired inconsistancy,
because source and NMDefaultRouteManager would disagree of whether
the source has a default route.
Source must always properly indicate whether it has a default route
or not, hence this situation does not arise.

Hence it is always better to call update().

Signed-off-by: Thomas Haller <thaller@redhat.com>
device: only add default route when having any addresses

This fixes the failure to add a default route because no
addresses are configured yet.

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: minor refactoring in NMDefaultRouteManager to access routes generically

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: consider additional assumed routes when synchronizing the default route

Don't only consider the best route of assumed devices when syncing the route
metrics. This fixes the following scenario:

Have em1 assumed, with two default routes (metric 20 and 21).
When activating em2, NMDefaultRouteManager would  have determined
21 as the effective metric, thus replacing the assumed route of em1.

Since we don't want to touch assumed interfaces, it is wrong to
replace their default routes.

Instead, keep track of all the assumed default routes and consider their
metrics when choosing effective_metric.

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: resync routes on platform change events

Monitor default routes from platform, and resync the default routes
on changes.

For one, this fixes the following use-case: have an assumed device em1
with two routes of metric 20 and 21. Activate em2, which will get effective
metric 22.
When externally removing route em1/20, em2 would resync the effective metric to
20. This is correct and already worked before. However, when deleting em1/21,
nothing happened. With this change, em2 would resync to metric 21 to fill the gap.

However this commit has much bigger effects: whenever the user externally adds
a default route to an interface for which NM manages an default route, NM will
delete it.
Also, when deleting the default route (managed by NM), NM would readd
it. Effectivly, the user can no longer mess with the default route on
interfaces for which it manages the default route.

If the connection is configured never-default, the user still can add
default routes and NM will not touch them.

Obviously, this has no effect for assumed devices either and the user
can externally add and remove default routes as he wishes.

https://bugzilla.gnome.org/show_bug.cgi?id=735512

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: pick up externally configured default routes for managed interfaces

The previous commit made NM enforce the default route on interfaces for
which NM manages a default route.

For interfaces that are configured never-default, NM will now pick up
any externally configured default route, as if it was managed by NM.
This is important, because NMDefaultRouteManager needs a notion of which
is the best device. Without this change, it was agnostic to default routes
on managed, never-default interfaces.

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: sort default routes by metrics before adding them

It's better to add the more important routes first. Otherwise there
might be a short time when a lower priority route has precedence.

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: fix handling managed devices without default route

Before, we would only track a device in NMDefaultRouteManager
if it had a default route. Otherwise the entry for the device
was removed.

That was wrong, because having no entry meant that the interface
is assumed and hence we would not touch the interface. Instead we must
esplicitly track devices without default route to know when an interface
has no default route.

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: enforce absence of default route on never-default VPN connections

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: merge branch 'th/bgo735512_route_metric_v2'

Further fixes to NMDefaultRouteManager.

https://bugzilla.gnome.org/show_bug.cgi?id=735512
platform: stop using private kernel tun device flags (bgo #740380)

The TUN_* flags are going to be deprecated upstream in the kernel
so we might as well stop using them.

https://lkml.org/lkml/2014/11/19/460

https://bugzilla.gnome.org/show_bug.cgi?id=740380
cli: Process secret agent request for a connection only if we know its path

If we're activating the device without knowing the connection in advance, defer
servicing the requests for the secrets until we set the path.

[lkundrak@fedora20-2 ~]$ nmcli --ask c ifname wlan0

(process:18405): libnm-CRITICAL **: nm_object_get_path: assertion 'NM_IS_OBJECT (object)' failed
Error: Connection activation failed: The device has no connections available.
[lkundrak@fedora20-2 ~]$
dispatcher: Fix tests

IP4_GATEWAY variable was added to the environment.

Fixes: 9a133787536452cc8e471efe6bc0c94e5ad43383
Merge remote-tracking branches 'fd/lr/ipv6-tokens', 'fd/lr/nm-1-0-fixes', 'fd/lr/unmanaged-slaves', 'fd/lr/device-activation' and 'fd/lr/veth-managed' into integration