The D-Bus interface already has a boolean property "Unsaved".

While that is nicer too look at (in the API), adding a new flag
is very cumbersome, and also has more overhead. For example,
it requires extending the D-Bus API, all the way down to libnm.

Add a flags argument, that will allow to add future boolean
flags easier.

This allows to adjust the timeout of an existing checkpoint.

The main usecase of checkpoints, is to have a fail-safe when
configuring the network remotely. By allowing to reset the timeout,
the user can perform a series of actions, and keep bumping the
timeout. That way, the entire series is still guarded by the same
checkpoint, but the user can start with short timeout, and
re-adjust the timeout as he goes along.

The libnm API only implements the async form (at least for now).
Sync methods are fundamentally wrong with D-Bus, and it's probably
not needed. Also, follow glib convenction, where the async form
doesn't have the _async name suffix. Also, accept a D-Bus path
as argument, not a NMCheckpoint instance. The libnm API should
not be more restricted than the underlying D-Bus API. It would
be cumbersome to require the user to lookup the NMCheckpoint
instance first, especially since libnm doesn't provide an efficient
or convenient lookup-by-path method. On the other hand, retrieving
the path from a NMCheckpoint instance is always possible.

Fixes: 8a46b25cfa8c33daa8af37bb8103ca02286001b1

If IPV6CP terminates before IPCP, pppd enters the RUNNING phase and we
start IP configuration without having an IP interface set, which
triggers assertions.

Instead, add a SetIfindex() D-Bus method that gets called by the
plugin when pppd becomes RUNNING. The method sets the IP ifindex of
the device and starts IP configuration.

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

Some targets are missing dependencies on some generated sources in
the meson port. These makes the build to fail due to missing source
files on a highly parallelized build.

These dependencies have been resolved by taking advantage of meson's
internal dependencies which can be used to pass source files,
include directories, libraries and compiler flags.

One of such internal dependencies called `core_dep` was already in
use. However, in order to avoid any confusion with another new
internal dependency called `nm_core_dep`, which is used to include
directories and source files from the `libnm-core` directory, the
`core_dep` dependency has been renamed to `nm_dep`.

These changes have allowed minimizing the build details which are
inherited by using those dependencies. The parallelized build has
also been improved.

Implement support for IP tunnel flags. Currently only some IPv6 tunnel
flags are supported. Example:

 # nmcli connection add type ip-tunnel mode ip6ip6 \
   ip-tunnel.flags ip6-ign-encap-limit,ip6-use-orig-tclass \
   ifname abc ip-tunnel.parent ens8 ipv4.method disabled \
   ipv6.method manual ipv6.address ::8888 remote ::42

 # ip -d l
  61: abc@ens8: <NOARP,UP,LOWER_UP> mtu 1460 qdisc noqueue ...
    link/tunnel6 :: brd ::42 promiscuity 0
    ip6tnl ip6ip6 remote ::42 local :: dev ens8 encaplimit none
    hoplimit 0 tclass inherit ...

https://bugzilla.gnome.org/show_bug.cgi?id=791846

meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.

[thaller@redhat.com: rebased patch and adjusted for iwd support]

https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00022.html

Extend the Update2 flags to allow marking a connection as volatile.
Making a connection as volatile means that the connection stays alive
as long as an active connection references it.

It is correct that Update2() returns before the connection is actually
deleted. It might take an arbitrary long time until the volatile
mechanism cleans up the connection.

Also add two more IN_MEMORY flags: "detached" and "only".

The existing NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY would not detach nor
delete the possible file on disk. That is, the mode only changes what NM
thinks is the current content of the connection profile. It would not delete
the file on disk nor would it detach the profile in-memory from the file.
As such, later persisting the connection again to disk would overwrite
the file, and deleting the profile, would delete the file.

Now add two new IN_MEMORY modes.

NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACH is like making the connection
in-memory only, but forgetting that there might be any profile on disk.
That means, a later Delete() would not delete the file. Similarly, a
later Update2() that persists the connection again, would not overwrite
the existing file on disk, instead it would choose a new file name.

On the other hand, NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY would delete
a potential file from disk right away.

It's clear that "volatile" only makes sense with either "in-memory-detached"
or "in-memory-only". That is, the file on disk should be deleted right away
(before the in-memory part is garbage collected) or the file on disk should
be forgotten.