Make NMSettingsService implement most of the NMSettingsInterface
API to make subclasses simpler, and consolidate exporting of
NMExportedConnection subclasses in NMSettingsService instead of
in 3 places. Make NMSysconfigSettings a subclass of
NMSettingsService and save a ton of code.
The old NMExportedConnection was used for both client and server-side classes,
which was a mistake and made the code very complicated to follow. Additionally,
all PolicyKit operations were synchronous, and PK operations can block for a
long time (ie for user input) before returning, so they need to be async. But
NMExportedConnection and NMSysconfigConnection didn't allow for async PK ops
at all.
Use this opportunity to clean up the mess and create GInterfaces that both
server and client objects implement, so that the connection editor and applet
can operate on generic objects like they did before (using the interfaces) but
can perform specific operations (like async PK verification of callers) depending
on whether they are local or remote or whatever.
The only thing that doesn't work yet is the system-settings service's
"auto eth" connections for ethernet devices that don't have an existing
connection. Might also have issues with unmanaged devices that can't
provide a MAC address until they are brought up, but we'll see.
Plugins no longer need to hash WPA passphrases, so there's no need to keep
sha1 stuff around unless its for hasing other stuff (ifcfg-rh uses sha1
for certificate hashing for example, but has a private copy).
The plugin called nm_exported_connection_update() which ended up checking
PolicyKit for authorization to update the connection, which of course fails
completely when it's just an inotify-triggered update. inotify-triggered
updates don't need authorization because they require root access anyway.
TLS uses the 'identity' which previously wasn't read. The private key
password should also only be used for PKCS#12 files, becuase they aren't
decrypted when read into the setting.
Private keys also need to be handled differently; PKCS#12 keys are written
out unchanged (ie, still encrypted) with their corresponding private key.
DER keys are stored in the setting unencrypted, so they are re-encrypted
before being written out to disk. But because the private key password
isn't known for DER keys, a random password must be used to re-encrypt
the key.
So that normal users who have PolicyKit authorization to edit system connections
can read secrets, move system connection secrets logic into the system connection
service from libnm-glib, and protect it with PolicyKit checks. Convert the
ifcfg-rh plugin over to using NMSysconfigConnection so that it can take advantage
of the new PolicyKit protection.
