Enforce dom0 salt state as part of preflight updates

[eloquence]

Some urgent security updates on deployed workstations (e.g., RPC policy changes) may need to be applied via provisioning logic that is managed via Salt. As an interim solution, we've agreed that it makes sense to enforce the dom0 salt state as part of the preflight updater merged in #396. This will add some time to the preflight update process; as before/after comparison, it would be good to stopwatch this added time as part of the review process.

[conorsch]

See previous discussion in #412 (comment). Specifically, it's qubesctl state.highstate that we want to make sure runs as part of the preflight updater. The drawback to targeting only dom0 is that state inside domUs can only be updated via deb packages, but we can reevaluate that strategy down the road if it proves insufficient. For the purposes of the pilot, we'll make sure there's a one-shot action to apply all state ad-hoc, exposed to Admins, for the purposes of support—that's tracked as a subtask of #406.

[emkll]

Noting for the implementer that the order of operations is important: we should apply the dom0 configuration before rebooting the AppVMs, to ensure changes to the templates are applied, in the event a reboot is not required.

In #432 , we introduced a securedrop-admin command. We should call it with --validate to validate the config (fail accordingly), and then --apply to apply the configuration (also fail accordingly).