The Settings.Connection interface is now only provided by NetworkManager
itself since there is only one settings service. NM can validate
requests for secrets internally and thus there's no need to lock down
GetSecrets using a separate D-Bus interface, since PolicyKit provides
that functionality on systems where this is desirable (ie multi-user).
Single-user systems that do not have PolicyKit will inherently trust
the user already, or if not D-Bus auth is flexible enough to lock
down the GetSecrets method individually even if it's not on a separate
D-Bus interface.
Second, since only clients like connection editors or applets will be
calling the GetSecrets method, there's no need for 'hints' or
'request_new' arguments here since this method should never trigger
an interactive secrets request. Only NM should send those requests
when it knows it needs to ask the user, either during connection or
after validating the incoming GetSecrets request. A connection editor
type application should never be able to trigger the normal
"What's your passphrase" dialog thats provided by the secret agent
for that user's session.
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.
