Having a goal of trying to put as much as possible into microshift binary we need some skeleton to put specific logic in right places.

We already know about following logical pieces of updateability:

• detect a status of previous boot (green vs red) - either green/red scripts, asking greenboot, or reading greenboot's vars in kernel cmdline
• performing a microshift data backup
• performing a microshift data rollback
• deciding whether to backup, rollback, or do nothing depending on status of previous boot
• persisting and reading microshift version to/from file
• comparing binary version to persisted version and deciding whether to run storage migration procedure
• running storage migration procedure (storage-migration-controller + etcd + kube-apiserver)

For each area we can see there are two phases: "decide" and "act". I'd like them to not be tied, but possible to run "decide" without "act" (e.g. with --dry-run), so integration testing of "deciding" what actions to perform and validating that these actions are correct can be split. It will be `microshift pre-boot/init/prepare/etc.` that runs them in sysd unit as "pre exec".