Converts F30 -> F31 in dev env

[conorsch]

Status

Ready for review.

Description of Changes

Refs #544

Changes proposed in this pull request:

These changes ensure that fedora-31 is preferred everywhere. Running a
make dev will ensure that the handle-upgrade logic is run, restarting
the VMs as required. What's not included in this change is a method
for handling automated upgrades in staging/prod. In order to accomplish
unattended transition from f30 -> f31, we'll have to update the dom0
state management logic to "include" the handle-upgrade script.

Testing

Make sure you use a dev environment (i.e. config.json shows "environment": "dev").

make clone
make all
make test

All tests should pass. On my machine, the only test that failed was the dnf update check, so after updating the packages in fedora-31, the test suite was passing completely.

Also run qvm-ls | grep fedora and ensure that sys-net, sys-usb, and sys-firewall are all based on fedora-31. (The tests check this, but best to be sure.) I've not yet confirmed the usb export flow to be working, so validation on that front is required, as well.

Checklist

If you have made code changes

• Linter (make flake8) passes in the development environment (this box may
  be left unchecked, as flake8 also runs in CI)

If you have made changes to the provisioning logic

• All tests (make test) pass in dom0 of a Qubes install

• This PR adds/removes files, and includes required updates to the packaging
  logic in MANIFEST.in and rpm-build/SPECS/securedrop-workstation-dom0-config.spec

[conorsch]

What's not included in this change is a method for handling automated upgrades in staging/prod.

On second thought, these changes may also be sufficient for staging/prod. Either way, let's defer testing of staging/prod for now, and focus on the dev story.

We haven't explicitly discussed whether these changes will be included in the 0.3.0 release. Given merge of #554, if this PR gets merged before the 0.3.0 is final, let's make sure to keep the changelog accurate.

[rmol]

This works, as long as you don't have any disp-mgmt VMs left around from interruptions. I started with a clone of current master, ran make clean and make all, then cloned 544-fedora-31-in-dev-env, ran make clean and make all, and got QubesVMInUseError: Cannot change template while there are DispVMs based on this qube at the sd-default-mgmt-dvm-fedora-version-update task.

After removing the management DispVMs (disp-mgmt-dvm-sd-log-buster-templat, disp-mgmt-securedrop-workstatio, and disp-mgmt-sys-firewall, in this case) based on default-mgmt-dvm, which was itself based on fedora-30, make all ran to completion without error, and everything seems to have been updated to Fedora 31.

So I'm approving, but will look into whether we should remove halted management DispVMs at the start.

[conorsch]

Thanks for the detailed review notes, @rmol!

will look into whether we should remove halted management DispVMs at the start

Sounds like a durability measure we'd want to accommodate, but it sounds like even the Qubes upstream updater would be affected. Assuming the disp-mgmt-* VMs were hanging around from a previously interrupted upgrade, we don't currently have a good recovery story, so let's aim to evalute whether our logging would clearly identify that error—I expect the call-python-from-bash approach currently used (cf. #539) means we'd miss the QubesVMInUseErrors.