Normalize coding style by removing consecutive empty lines from C
sources and headers.

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

Up to now, it was not visible on D-Bus whether a connection
was generated by NetworkManager and/or volatile.

That is for example interesting for firewalld, which aims
to store persistant configuration in NetworkManager's profile.
However, that doesn't make sense for external connections
(which are nm-generated & volatile). In fact, it probably
makes no sense for volatile connections in general, because
modifying them, likely makes them non-volatile (depending on
how the profile is modified).

Also, the Update2() D-Bus operation allows to carefully
make connections volatile and unsaved. As we have public
API to set these flags, we should also expose them on D-Bus.

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

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.

Note that this changes API for checkpoint_create_async() in Python
via GIR. Previously it would require an integer argument, now a flags
argument. But this API is still unstable, it will be introduced with
1.12.

Introduce a new flag NM_CHECKPOINT_CREATE_FLAG_ALLOW_OVERLAPPING
that allows the creation of overlapping checkpoints. Before, and
by default, checkpoints that reference a same device conflict,
and creating such a checkpoint failed.

Now, allow this. But during rollback automatically destroy all
overlapping checkpoints that were created after the checkpoint
that is about to rollback.

With this, you can create a series of checkpoints, and rollback them
individually. With the restriction, that if you once rolled back to an
older checkpoint, you no longer can roll"forward" to a younger one.

What this implies and what is new here, is that the checkpoint might be
automatically destroyed by NetworkManager before the timeout expires. When
the user later would try to manually destroy/rollback such a checkpoint, it
would fail because the checkpoint no longer exists.

Add a new device state reason code for unsupported IP method. It is
returned, for example, when users select manual IP configuration for
WWAN connections:

 # nmcli connection mod Gsm ipv4.method manual ipv4.address 1.2.3.4/32
 # nmcli connection up Gsm
 Error: Connection activation failed: The selected IP method is not
 supported

compared to the old:

 Error: Connection activation failed: IP configuration could not be
 reserved (no available address, timeout, etc.)

Note that we could instead fail the connection validation if the
method is not supported by the connection type, but adding such
limitation now could make existing connections invalid.

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

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.

We already have Update(), UpdateUnsaved() and Save(), which serve
similar purposes. We will need a form of update with another argument.

Most notably, to block autoconnect while doing the update.

Other use cases could be to prevent reapplying connection.zone and
connection.metered, to to reapply all changes.

Instead of adding a specific update function that only serves that
new use-case, add a extensible Update2() function. It can be extended
to cope with future variants of update.