overlord/ifacestate: store the set of intended connections in the state

[zyga]

This branch adds the concept of Intent that is persistently stored by the interfaces manager.

When a connection is requested this fact is stored as an intent in the state. The operation is undone
for disconnections. Intents are persistent as they express an action that the system operator has performed.

Intents are also about to play an essential role when generating security on snap updates as they will be used to know which connections should be re-established when the snap changes.

[pedronis]

how will you handle when you have the intent, and a pending change for the same connection because of a restart? shouldn't intents be just called plug-connections and be set when the change is about done?

[zyga]

I'm not sure if this answers your question but on Init() I'd like to load intents, add all snaps to the repository and spawn all the connect tasks for each of those. This will at least try to re-construct back the same state we were left off before reboot.

There is still some more work to be done for across reboots and this will be more and more interesting as we add hooks which can make each reboot rebuild the same set of intents to a different set of connections and their parameters (because hooks can alter attributes and can also fail).

Currently the actual side-effects of each connection are persistent across reboots (config for apparmor/seccomp/dbus/udev) and they are made effective even before snapd starts up (with systemd units). I wonder if given this fact we should simply persist connections directly.

I went with persistent intents vs persistent connections because I think we will move away from that model as it cannot support dynamic hooks completely.

[zyga]

I'll switch this over to "the state of the system" (so not intent, the actual connection) and reopen