When a device is unmanaged, an explicit activation request can
still activate it.

In particular, that is the case for

  nmcli connection up "$PROFILE" ifname "$DEVICE"

It is also the case, for

  nmcli connection up "$PROFILE"

alone, where NetworkManager searches for a suitable device.

Previously, that would also always consider unmanaged devices
as suitable candidates. I think that makes sense, as usually
a profile is strictly tied to a device via matches like
"connection.interface-name".

However, for profiles with "connection.multi-connect" not "single",
it seems this behavior is not best. Here, the profile is commonly
not tied to one device, but multiple. So, we probably should not
consider unmanaged devices as suitable candidates.

Change the behavior for such profiles. Note, that now the behavior
differs depending on "connection.multi-connect", which can be seen as
inconsistancy. I think it is preferable, because exactly a
multi-connect "single" profile indeed should be tied to one device.
Which is for example what `nmcli connection add` suggest, by requiring
an "ifname" argument. If the profile is tied to a device, the user's
intent is clear and it should not require an explict

  nmcli device set "$DEVICE" managed yes

call first.

https://bugzilla.redhat.com/show_bug.cgi?id=1639254

This flag is more granular in whether to consider the connection
available or not. We probably should never check for the combined
flag NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST directly, but
always explicitly for the relevant parts.

Also, improve the error message, to indicate whether the device is
strictly unmanaged or whether it could be overruled.

The flags NMDeviceCheckConAvailableFlags and NMDeviceCheckDevAvailableFlags
both control whether a device appears available (either, available in
general, or related to a particular profile).

Also, both flag types strictly increase availability. Meaning: more flags,
more available.

There is some overlap between the flags, however they still have
their own distinct parts.

Improve the mapping from NMDeviceCheckConAvailableFlags to
NMDeviceCheckDevAvailableFlags, by picking exactly the flags
that are relevant.

We should not check @sett_conn, but @connection.

Fixes: 09719bc479b63c8e5fef3950e980b263aca7eff5

With

  $ nmcli connection up "$PROFILE" ifname "$DEVICE"

it's clear that the user means the particular device. That also
is taken as a indication to make $DEVICE as managed, in case it was
unmanaged before. So, this command implies a previous

  $ nmcli device set $DEVICE managed yes

On the other hand, if the user just issues

  $ nmcli connection up "$PROFILE"

without a particular device, then we should prefer devices which
are marked as managed instead of unmanaged once.

Likewise, we should consider the device's state when selecting
a device. This means, when activating a profile which is activatable on
multiple devices, it will now prefer devices which are not already
active. The exception to this is that if the profile itself is already
active (and multi-connect "single"), then it will prefer to re-activate
the profile on the same device. This was done previously already. What's
new is that if the the profile is not multi-connect "single", the said
exception no longer applies, and we prefer to activate the profile on a
hitherto unactivated device.

https://bugzilla.redhat.com/show_bug.cgi?id=1639254

https://github.com/NetworkManager/NetworkManager/pull/232

https://bugzilla.redhat.com/show_bug.cgi?id=1608323
(cherry picked from commit d7d085a88d6207c8362834adf407e807e9a89b68)

https://github.com/NetworkManager/NetworkManager/pull/217

We shouldn't start a grace period when the client is not running.