When a device is removed (like when the user unplugs a usb network
device) the device object is removed, so it doesn't emit a notify signal
for a change in its connectivity and so, device_connectivity_changed
is not called. This means that nobody updates the global connectivity
value which is potentially wrong if the device was the one providing
network connectivity.

Since device_connectivity_changed's first two parameters aren't actually
used and are there just for the signal to be able to be connected, I
moved the code from device_connectivity_changed to a new
update_connectivity_value function that just takes a NMManager
parameter and also call it from remove_device.

[thaller@redhat.com: fix coding style regarding whitespace]

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/141

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/101

This change allows NM to assume after a restart a device that has been
enslaved externally to an ovs bridge.

https://bugzilla.redhat.com/show_bug.cgi?id=1676551
(cherry picked from commit 93bbe436958264d5f720ce095b3f390ce50fc732)

"nm-macros-interal.h" already includes <errno.h> and <string.h>.
No need to include it everywhere else too.

AddAndActivate2 returns an empty a{sv} dictionary for extensibility. The
format strings to create the methods return value were slightly wrong,
causing assertion failures.

Fixes: fbb038af5e5d675c994de26da676edfd8e73ffbe

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/73

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/64

Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API.
"AddAndActivate2" replaces "AddAndActivate" with more options.
It also has a dictionary argument to be forward compatible so that we
hopefully won't need an "AddAndActivate3". However, it lacked a similar
output dictionary. Add it for future extensibility. I think this is
really to workaround a shortcoming of D-Bus, which does provide strong
typing and type information about its API, but does not allow to extend
an existing API in a backward compatible manner. So we either resort to
Method(), Method2(), Method3() variants, or a catch-all variant with a
generic "a{sv}" input/output argument.

In libnm, rename "nm_client_add_and_activate_connection_options()" to
"nm_client_add_and_activate_connection2()". I think libnm API should have
an obvious correspondence with D-Bus API. Or stated differently, if
"AddAndActivateOptions" would be a better name, then the D-Bus API should
be renamed. We should prefer one name over the other, but regardless
of which is preferred, the naming for D-Bus and libnm API should
correspond.

In this case, I do think that AddAndActivate2() is a better name than
AddAndActivateOptions(). Hence I rename the libnm API.

Also, unless necessary, let libnm still call "AddAndActivate" instead of
"AddAndActivate2". Our backward compatibility works the way that libnm
requires a server version at least as new as itself. As such, libnm
theoretically could assume that server version is new enough to support
"AddAndActivate2" and could always use the more powerful variant.
However, we don't need to break compatibility intentionally and for
little gain. Here, it's easy to let libnm also handle old server API, by
continuing to use "AddAndActivate" for nm_client_add_and_activate_connection().
Note that during package update, we don't restart the currently running
NetworkManager instance. In such a scenario, it can easily happen that
nmcli/libnm is newer than the server version. Let's try a bit harder
to not break that.

Changes as discussed in [1].

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876

Don't return success from a nested code path. Handle all errors
first, and return early. Well, we cannot really return right away
because we need to handle the failure. So, at least, check for errors
and "goto fail".