This is useful for manually testing Update2() D-Bus API.

This is useful for manually testing AddConnection2() D-Bus API.

Use the script to test how GObject introspection with libnm's WireGuard
support works.

Also, since support for WireGuard peers is not yet implemented in nmcli
(or other clients), this script is rather useful.

It's not an example and not actually used.

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

We need common operations from the python scripts.
For example, to print the boot-time.

Move such utils to a separate nmex.py file ("ex" for
example). This file should contain helper functions that
are pure python (or, if the have requirements, load them
only on demand, so that examples that need those have
additional dependencies). It should also be simple to extract
individual helpers from nmex, so that the user can take an
example, merge parts of nmex.py in, and modify it to his needs.

It already defaults to the right value. We only need to define
NM_VERSION_MIN_REQUIRED, so that parts of our internal build
can make use of deprecated API.

We don't need to have two version defines "CUR" and "NEXT".

The main purpose of these macros (if not their only), is to
make NM_AVAILABLE_IN_* and NM_DEPRECATED_IN_* macros work.

1) At the precise commit of a release, "CUR" and "NEXT" must be identical,
because whenever the user configures NM_VERSION_MIN_REQUIRED and
NM_VERSION_MAX_ALLOWED, then they both compare against the current
version, at which point "CUR" == "NEXT".

2) Every other commit aside the release, is a development version that leads
up the the next coming release. But as far as versioning is concerned, such
a development version should be treated like that future release. It's unstable
API and it may or may not be close to later API of the release. But
we shall treat it as that version. Hence, also in this case, we want to
set both "NM_VERSION_CUR_STABLE" and again NEXT to the future version.

This makes NM_VERSION_NEXT_STABLE redundant.

Previously, the separation between current and next version would for
example allow that NM_VERSION_CUR_STABLE is the previously release
stable API, and NM_VERSION_NEXT_STABLE is the version of the next upcoming
stable API. So, we could allow "examples" to make use of development
API, but other(?) internal code still restrict to unstable API. But it's
unclear which other code would want to avoid current development.

Also, the points 1) and 2) were badly understood. Note that for our
previousy releases, we usually didn't bump the macros at the stable
release (and if we did, we didn't set them to be the same). While using
two macros might be more powerful, it is hard to grok and easy to
forget to bump the macros a the right time. One macro shall suffice.

All this also means, that *immediately* after making a new release, we shall
bump the version number in `configure.ac` and "NM_VERSION_CUR_STABLE".

Although it is possible to generate distributable files on meson
since version 0.41 by using the `ninja dist` command, autotools does
different things that end up creating a different distributable
file.

meson build files have been added to autotools build files as
distributable files, so the whole meson port would also be
distributed.

https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00047.html

The example script touches the stable-id of a connection.
It does so blocking autoconnect, and was originally written
to test that functionality.

Converted from python/gi/get_ip.py.