Until now, NetworkManager tries to "assume" connections on externally
configured devices.

This behavior is fundamentally wrong because "assuming" has two
contradicting meanings:

a) for one, it means not to touch externally configured devices that
  are not supposed to be managed by NetworkManager. NetworkManager goes
  through   great lengths trying not to mess with such devices, most
  notably software devices like a bridge. NetworkManager does this, to
  present the interface as up and configured, although this is a
  pretend-only mode and the device is not managed by NetworkManager.
b) it also has the meaning during restart, where NetworkManager leaves
  interfaces up during exit and tries to take them over on start. In
  this case, NetworkManager wants to manage the device, but it wants to
  take it over non-destructively, without breaking connectivity.

These are fundamentally different things, because for a) NetworkManager should
not touch the interface at all, while for b) it very much should touch it,
for example to extend DHCP leases and renew addresses.

Until now, this was done by generating an in-memory connection and trying to
match it to any of it's existing setting profiles. If a match is found, that
connection will be assumed, otherwise the generated connection is added as
in-memory connection.
Other then that, there is little difference between whether
NetworkManager is able to match an existing connection or whether
it uses the generated connections. In some cases it affects whether
to lean more towards behavior a) or b). But of courese, the match itself
is only a guess and NetworkManager doesn't make up it's mind whether it wants
to manage the device or not.

Fix that. Now, NetworkManager decides early what to do and whether to manage
the device (b) or not (a). For one, NetworkManager will store the state of the
devices during exit in /var/run/NetworkManager/devices. Thus, after a restart,
NetworkManager knows whether it managed the device before or not. In case
NetworkManager is started the first time since boot, the decision is made
based on user-configuration, UDEV, and default behaviors. Default behaviors
are for example that existing software devices are unmanaged by default,
while real devices default to be managed.

Therefore, the case a), really becomes having external devices as unmanaged.
NetworkManager will no longer pretend a connection is active. This for
example means that no dispatcher events will run for previously assumed
devices. Such a pretend-only, active state could be reintroduced later.

If NetworkManager decides to manage the device (b), it will now move
the device through states unavailable/disconnected, and eventually
autoconnect will start as usual. The graceful take-over is done
only when the run-state file indicates a connection that was active
previously on the device. In that case, NetworkManager will assume
that connection. But once full activation state is reached, an assumed
connection is not any different from a regular
activation/autoactivation.

This of course changes existing behavior in many ways. This is only
a first commit, surely there are many follow up issues.

A lot of code becames now unused. This will be removed in later commits
to keep the diff smaller.

https://bugzilla.gnome.org/show_bug.cgi?id=746440
https://bugzilla.redhat.com/show_bug.cgi?id=1394579

We used the unmanage flag "external-down" for software devices that
were created outside of NetworkManager. The "external-down" flag kept
the device as unmanaged, until the interface was up and had an IP address.
That is wrong to do.

Instead, replace the flag by NM_UNMANAGED_BY_DEFAULT, which marks all
software devices that were created outside of NetworkManager as unmanaged.
This is regardless of their IP configuration. If a software device was not
created by NetworkManager it is fair to assume that the user wants to manage
it himself and doesn't want NetworkManager to interfere.

Note that the unmanged flags "user-udev" and "user-explicit" have higher
priority then the "by-default" flag. This way it will be still possible to
manage devices that would be otherwise unmanaged.

This breaks behavior in many ways, which will be only fixed by later commits.

An EXTERNAL activation type comes with a nm-generated, garbage-collected,
in-memory connection. When the user actively modifies that connection, we
shall mark the active connection as fully managed.

Before, we would have the concept of assumed connections, which is used
for (1) externally configured device that NetworkManager should not
touch and (2) connections that NetworkManager should gracefully take
over after a restart (seamless, non-destructive).

The behavior was really mixed there. It wasn't really clear whether
NetworkManager is in no-touch mode (1) or gracefully take-over (2).
Previous commits already clean that up by having an activation type
EXTERNAL (1) vs. ASSUME (2).

Also, previously, we would for both (1) and (2) try to find a matching
connection and use it. That doesn't make sense for either.

In external case (1), we should not pretend that an existing connection
is active. Let's always create a new in-memory connection for these
cases. Note that this means, external devices now will always generate
a connection, instead of pretending an existing is active.

For the assume case (2), we shall not use nm_utils_match_connection() to
guess which connection might be active. It can only the one that was
active on a previous run of NetworkManager. So, use the information from
the state file and try to activate it. If that fails, it is not an
assume activation type. Note, that this means we now most of the time
don't do ASSUME anymore. Most of the time we do EXTERNAL activation
That is because the state information is only available after restart
of NetworkManager.

We need a distinction between external activations and assuming
connections. The former shall have the meaning of devices that are
*not* managed by NetworkManager, the latter are configurations that
are gracefully taken over after restart (but fully managed).

Express that in the activation-type of the active connection.

Also, no longer use the settings NM_SETTINGS_CONNECTION_FLAGS_GARBAGE_COLLECT
flag to determine whether an assumed connection is "external". These
concepts are entirely orthogonal (although in pratice, external
activations are in-memory and flagged for garbage collection.

The change to match_connection_filter() to also consider connections
that are marked for garbagecollect will later make more sense,
where we only do nm_utils_match_connection() for assumed connection
but skip it for external activation-type.

nm_device_uses_assumed_connection() basically called
nm_active_connection_get_assumed() on the device.

Rename those functions to be closer to the activation-type
flags.

It is still unused, but will be useful to mark a connection
whether it is a full activation or assumed.

This will cleanup the existing

On restart, the device state may be stored in /var/run. Reuse it
to set the managed flag.