Using the "placeholder" top file strategy identified by @marmarek, in
order to trigger automatic VM boots when Salt tasks target the VMs.
Otherwise, Salt will report "SKIPPED" on the powered off VMs. Rather
than manually boot the VMs each time we want to provision them, then
power them off again, let's let Salt handle that.

The 'securedrop-update' script can be run interactively by Admins, and
is also configured to run once daily via cron, to ensure that updates
are applied on a rather regular schedule.

We intend to package these dom0-specific config items into an RPM, but
for now we'll continue to use Salt to copy the files around via the
Makefile.

Note that the `sd-dom0-files.sls` filename implies the list is
comprehensive, but in fact there are dom0-specific configs scattered
through the other SLS files, mostly VM specifications and RPC policy
grants.

Factored in some advice received during pre-review. For now we're taking
an interative approach to automating the updates. Currently we want,
in order:

  1. All dom0 RPMs up to date
  2. All TemplateVMs up to date with packages (either RPMs or debs)

What's not yet implemented is a strategy to automatically enforce the VM
state regularly. That'll likely be a `qubesctl state.highstate` command,
but punting for now to simplify testing of this already significant
change.

Tackling requested changes during review:

  * supports custom dom0 usernames
  * omits --templates on pkg upgrade to include dom0
  * uses state.highstate to enforce VM config
  * notify about reboot request (so updates are applied)

We'll want to clean up the reboot recommendation once we have more UX
feedback. For now, it's enough to notify that updates aren't actually in
effect (due to AppVMs not having been restarted).

- remove comments that were already addressed
- restore dom0 package updates
- perform update package action only in templates

It seems like the flake8 container/rules have changed, mostly
indentation.

Ignore W605 is for invalid escape sequence '\s' in test_gpg.py:16

Pointed out by @joshuathayer during review; the "SecureDrop:" prefix was
redundant, since it's added by the display function.

During review, @emkll caught that not all apt packages were updated as
expected. These tests are a bit aggressive, and will fail if the AppVMs
haven't been rebooted recently. That's a bit annoying, but I'd rather
accept that friction than have a regression in the automatic upgrade
logic.

Without `dist_upgrade=true`, the pkg.upgrade wasn't forcing all packages
to their latest versions. This approach works well on Debian-based VMs,
as all the SecureDrop Workstation components currently are, but there's
a significant drawback: it silently fails on Fedora-based VMs, stating
that the "--dist_upgrade" option is not valid for dnf. You must pass
`--show-output` in order to observe the dnf failures; without it, the
tasks are reported as "OK".

Tried to use the "pkg.uptodate" Salt module rather than "pkg.uptodate",
but the Qubes VMs reported that module wasn't available.

The "dist_upgrade" option isn't explicitly documented [0], but presumably
gets inherited via Salt magic from the aptpkg.upgrade module [1].

Adding `--skip-dom0` since we already upgraded dom0 packages via a
previous step (qubes-dom0-update).

[0] https://docs.saltstack.com/en/2017.7/ref/states/all/salt.states.pkg.html#salt.states.pkg.uptodate
[1] https://docs.saltstack.com/en/2017.7/ref/modules/all/salt.modules.aptpkg.html#salt.modules.aptpkg.upgrade