Plugins that could save connections to disk previously depended on inotify
events from the kernel to know when to signal connection removal; that is
in response to a 'delete' request they would unlink the backing filesystem
resources, get the inotify signal, and cause NM_SETTINGS_CONNECTION_REMOVED
to be emitted.

Unsaved connections don't have any backing resources, so they would never
get the signal emitted, and NMSettings would never forget about them.

Also, when monitor-connection-files=false in the configuration, obviously
the inotify signals will never come in because they aren't set up.

Given that we can no longer rely on inotify, it's best to just explicitly
send out the NM_SETTINGS_CONNECTION_REMOVED signal whenever a connection
is deleted via the D-Bus interface or internally.

Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.

To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.

We don't always want to immediately write new connections to disk, to
facilitate "runtime" or "temporary" connections where an interface's
runtime config isn't backed by on-disk config.  Also, just because
an interface's configuration is changed doesn't necessarily mean
that new configuration should be written to disk either.

Add D-Bus methods for adding new connections and for updating existing
connections that don't immediately save the connection to disk.

Also add infrastructure to indicate to plugins that the new connection
shouldn't be immediately saved if the connection was added with the
new method.

If the connection doesn't yet have a conn_name, that means it's not
yet saved to disk.

We'll need this for later with unsaved connections.  The ifnet
plugin previously tracked connections by the "conn_name" which
was derived from keys in the /etc/conf.d/net file.  These keys
take two forms:

1) interface name

config_eth0=(
"192.168.4.121/24"
"dhcp6"
)

2) wifi SSID, either text or hex-encoded:

config_myssid=("dhcp")
config_0xab3ace=("dhcp")

The conf.d net connection name is apparently usually an interface
name, so when writing to /etc/conf.d/net the NM connection name is
changed from eg "Ethernet connection 1" to the next available
interface name based on the type of connection, eg "eth0".

The ifnet plugin actively removed connections that were not present
in /etc/conf.d/net during the reload_connections() call, but in the
future we'll want to allow unsaved connections which in the case of
ifnet clearly won't yet be written to the file.  Since only
connections written to the file have a "conn_name", tracking
connections by conn_name no longer works.

Add some new API to NMConfig so that NMSettings and its plugins can
use NMConfig to look up values rather than reparsing the config file
themselves.

Also, move the no-auto-default cache from NetworkManager.conf to
$NMSTATEDIR/no-auto-default.state, so NM isn't rewriting its own
config file at runtime.

They can just call nm_config_get() now to get the config, and
nm_config_get_path() to get its path.

Virtual devices often don't have stable hardware addresses. So allow
for marking a device unmanaged via its interface name instead.

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

GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).

So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.

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

Can't leave the backup files lying around when doing 'make distcheck',
so when backup up a file, return the backup file path so that the
caller can (optionally) remove it.