It's the thing that owns the secrets anyway, and it simplifies things to
have the secrets handling there instead of half in NMActRequest and
half in NMManager. It also means we can get rid of the ugly signals
that NMSettingsConnection had to emit to get agent's secrets, and
we can consolidate the requests for the persistent secrets that the
NMSettingsConnection owned into NMSettingsConnection itself instead
of also in NMAgentManager.
Since the NMActRequest and the NMVPNConnection classes already tracked
the underlying NMSettingsConnection representing the activation, its
trivial to just have them ask the NMSettingsConnection for secrets
instead of talking to the NMAgentManager. Thus, only the
NMSettingsConnection now has to know about the agent manager, and it
presents a cleaner interface to other objects further up the chain,
instead of having bits of the secrets request splattered around the
activation request, the VPN connection, the NMManager, etc.
Since settings storage is now handled by NetworkManager, we must
have the ability to read/write all connection types at all times.
Since the 'keyfile' plugin is the only plugin that can handle all
connection types, build it into NetworkManager.
Given connection details, complete the connection as well as possible
using the given specific object and device, add it to system
settings, and activate it all in one method.
New connections should not be pushed out in the Updated signal
because signals cannot be restricted to particular clients, and
some clients may not have permission to view the connection.
Upon receiving the Updated signal, clients should re-read the
connection using GetSettings to ensure that the client still
has permissions to view the connection, and to get the updated
settings.
Since user interaction is allowed when the permission for SaveHostname
is requested, if the user didn't authorize completely when polkit
returns, we don't want to proceed with the request. Otherwise we might
get into a situation where it's possible for the user to authorize,
but they didn't, and previously the code would allow the request.
Need to make sure we actually export the connection over D-Bus (via
claim_connection()) before we try to return its object path in the
AddConnection reply. Second, we need to send the path as a string
in the reply, not an object, since the return type is an object path.
