disabled services are re-enabled after revert

[Ian Johnson]

This is similar to #1818306, but I think is different enough that it warrants additional thought and design separate from that problem.

I'm not 100% convinced on what should be done about the state of services from a snap after a revert happens. Should the services be restored to their set of "enabled/disabled" state from when the revision we are refreshing to (i.e. the old revision before the snap was refreshed), or should the services be restored to the set of "enabled/disabled" states from the new revision? I think that the services should be restored to their state from the old revision when we refresh to that revision.

Whatever the design should be, the current behavior is that after a revert, all services in the snap are enabled and started. This sems wrong, and I would suggest that snapd should save what the daemon enabled/disabled states are for particular revisions so that a revert back to that state happens, it's restored. For example you would have this sequence of operations:

1. Install snap "test" (say revision 1) with test1 daemon -> it is started automatically and is enabled
2. Disable daemon "test1" with `snap stop --disable test.test1`
3. Refresh to new revision 2 of "test" with test1 daemon and new "test2" daemon - both started automatically and enabled
4. The snap is reverted back to revision 1 with `snap revert test --revision 1`
5. The "test1" daemon is disabled and not automatically started

If we use the state of services from the new revision, we potentially have additional unused state for additional services not present in the old revision and (more problematic I think) there's also the possibility of the new revision not containing some services and thus not having any information about what the state of those new services should be after the revert happens.