Safely shut down sys-usb; tweak logging

[eloquence]

Status

Ready for review

Description of Changes

Resolves #531. Makes logging slightly more verbose to help diagnose issues with specific VMs.

sys-whonix is now treated as a "safe to shut down" system VM along with sys-usb (sd-whonix does not depend on it running).

Testing

Preparatory steps

(All testing should be done with an existing Qubes install at least at 0.2.4-rpm - dev, prod or staging should make no difference)

1. Apply the changes in this PR to the launcher versions in /opt/securedrop/launcher and /srv/salt/launcher (if only the /opt copy is overwritten, the updater itself will replace it on the next run).
2. Downgrade zlib (dnf downgrade zlib) in fedora-30 to ensure a realistic update scenario. Power off fedora-30.

Scenario: fedora-30 update

1. Run /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0. This forces an updater run.
2. • Observe that the update completes successfully and that the zlib package in fedora-30 is now at the latest version
3. • Observe that no unexpected errors are logged in ~/.securedrop_launcher/logs/launcher.log
4. • Observe that sys-usb is running as expected and that the sd-devices workflow (automatic attachment of a LUKS-encrypted USB block device or USB printer to sd-devices) still works.

You may still encounter #498 due to the continued use of qvm-kill.

Checklist

• Linter (make flake8) passes in the development environment (this box may
  be left unchecked, as flake8 also runs in CI)
• All tests (make test) pass in dom0 of a Qubes install (N/A, updater has its own test suite which passes)
• No package updates required

[conorsch]

Have not reviewed yet, but did take the liberty of rebasing on latest master (8bfd1cf). I've had the sys-usb problem bite me on updater runs recently, so looking forward to reviewing, although likely not till next week.

[eloquence]

Tested in Qubes including with sys-whonix change in 4e54c89, did not encounter our friend #498 but I expect it will only be completely gone once we get rid of qvm-kill (and maybe even poll for successful VM startup given the HVM boot time).

[conorsch]

Works well! Ran through the test plan, detected no problems. The sys-usb kill action has been problematic for me in the past, but wasn't able to observe any breakage on this branch. Merging, will continue to monitor behavior and reopen issue if I can spot the problem again post-merge!