In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.

When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:

  ./a.c
    #include <stdio.h>
    #include <nm-1.h>
    void main() {
        printf ("INCLUDED %s/nm-2.h\n", SYMB);
    }

  ./1/nm-1.h
    #include <nm-2.h>

  ./1/nm-2.h
    #define SYMB "1"

  ./2/nm-2.h
    #define SYMB "2"

$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h

Exceptions to this are
  - headers in "shared/nm-utils" that include <NetworkManager.h>. These
    headers are copied into projects and hence used like headers owned by
    those projects.
  - examples/C

This speeds up the initial object tree load significantly. Also, it
reduces the object management complexity by shifting the duties to
GDBusObjectManager.

The lifetime of all NMObjects is now managed by the NMClient via the
object manager. The NMClient creates the NMObjects for GDBus objects,
triggers the initialization and serves as an object registry (replaces
the nm-cache).

The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
object creation, removal and property changes. It takes care of the
property changes so that we don't have to and lets us always see a
consistent object state.  Thus at the time we learn of a new object we
already know its properties.

The NMObject unfortunately can't be made synchronously initializable as
the NMRemoteConnection's settings are not managed with standard
o.fd.DBus Properties and ObjectManager APIs and thus are not known to
the ObjectManager.  Thus most of the asynchronous object property
changing code in nm-object.c is preserved. The objects notify the
properties that reference them of their initialization in from their
init_finish() methods, thus the asynchronously created objects are not
allowed to fail creation (or the dependees would wait forever). Not a
problem -- if a connection can't get its Settings, it's either invisible
or being removed (presumably we'd learn of the removal from the object
manager soon).

The NMObjects can't be created by the object manager itself, since we
can't determine the resulting object type in proxy_type() yet (we can't
tell from the name and can't access the interface list). Therefore the
GDBusObject is coupled with a NMObject later on.

Lastly, now that all the objects are managed by the object manager, the
NMRemoteSettings and NMManager go away when the daemon is stopped. The
complexity of dealing with calls to NMClient that would require any of
the resources that these objects manage (connection or device lists,
etc.) had to be moved to NMClient. The bright side is that his allows
for removal all of the daemon presence tracking from NMObject.

This is required to add objects in the "Types and Values" section and
in the API index. Later, we may want to add useful content in those
empty comments.

Consolidate NMClientError and NMObjectError (such that there is now
only one libnm-API-specific error domain). In particular, merge
NM_CONNECTION_ERROR_CONNECTION_REMOVED with
NM_OBJECT_ERROR_OBJECT_CREATION_FAILURE as the new
NM_CONNECTION_ERROR_OBJECT_CREATION_FAILED.

Also make object_creation_failed() be a plain method rather than a
signal, since there's no reason for anyone to be connecting to it on
another object. And remove its GError argument because the subclass
can just create its own more-specific error.

Add nm-types.h defining all the type structs, to avoid future include
loops. Clean up the includes in all of the installed headers.

Commit b732380d1eb86d4278578559b0ec00990202e3fc removed the gobject
property "NMObject:connection". However, this property is still needed
to inject the DBUS connection when creating new proxy objects. Without it,
we call _nm_dbus_new_connection() in the constructor for every proxy NMObject.

In case of non-private connections, g_bus_get_sync() already returns the same
connection. However for private connections, g_dbus_connection_new_for_address_sync()
would create a separate DBUS connection.

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

Signed-off-by: Thomas Haller <thaller@redhat.com>

Port libnm-core/libnm to GDBus.

The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).

The only plausible use case for the NMObject:dbus-connection property
is for using the session bus in test programs. So just drop it and use
an environment variable to decide which bus to use instead.

NMRemoteConnection had two DBusGConnection properties
(NMRemoteConnection:bus and NMRemoteConnection:dbus-connection) and
two D-Bus path properties (NMConnection:path and
NMRemoteConnection:dbus-path). The former of each pair were the
traditional names, and the latter were added for compatibility with
NMObject.

In libnm, we can just drop NMRemoteConnection:bus, and use the
NMObject-compatible :dbus-connection name instead.

For the path properties, we need to rename either NMConnection:path or
NMObject:dbus-path. Since NMObject already has "nm_object_get_path()"
rather than "nm_object_get_dbus_path()", and it already mistakenly
referred to the property as "NMObject:path" in the gtk-docs, it seemed
to make sense to rename that one rather than the NMConnection one.

(And then, for consistency, rename "nm_object_get_connection()" to
"nm_object_get_dbus_connection()" to also match its property.)

Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).

Fix this by changing the include guards in the non-API-stable parts of
the tree:

  - libnm-glib/nm-ip4-config.h remains   NM_IP4_CONFIG_H
  - libnm/nm-ip4-config.h now uses     __NM_IP4_CONFIG_H__
  - src/nm-ip4-config.h now uses       __NETWORKMANAGER_IP4_CONFIG_H__

And likewise for all other headers.

The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.