Fixes: a8d600525643 ('libnm: implement support for DNS manager properties')

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

Various annotations were added using multiple colons, while only one has
to be added or g-ir-introspect will consider them part of the description

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/94
(cherry picked from commit 73005fcf5b957a4cf7f8244da85ade0214db7606)

Detected via valgrind:

  $ ./tools/run-nm-test.sh -m -v libnm/tests/test-nm-client -p /libnm/active-connections

Fixes: fbb038af5e5d675c994de26da676edfd8e73ffbe

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

After renaming the files, also rename all the content
to follow the "Wi-Fi P2P" naming scheme.

We named the types inconsistently:

  - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h")

  - "p2p" ("libnm/nm-p2p-peer.h")

  - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h")

It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi"
specific name. It's not just peer-to-peer, it's Wi-Fi P2P.
Yes, there is an inconsistency now, because there is already
"libnm/nm-access-point.h".

It seems to me (from looking at the internet), that the name "Wi-Fi P2P"
is more common than "P2P Wi-Fi" -- although both are used. There is also
the name "Wi-Fi Direct". But it's not clear which name should be
preferred here, so stick to "Wi-Fi P2P".

In this first commit only rename the files. The following commit will
rename the content.

This adds the introspection data and P2P peer handling to libnm. To be
usable the P2P device handling is also needed.

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

"bind" specifically binds the lifetime of the activation (NMActiveConnection).
In combination with "persist=volatile", the lifetime of the NMSettingsConnection
is indirectly bound to the NMActiveConnection. But still these concepts make sense
independently.
In the future, it may make sense to also bind the lifetime of the NMSettingsConnection
to the D-Bus client. Hence, rename the option to allow for the distinction.

Also, belatedly fix libnm comment about "bind" only working with
"persist" "volatile".

Fixes: eb883e34a5889812d35e5c2d7bc6051723001a3a