Add detailed logging to separate logfile

[eloquence]

Status

Ready for review

Description of Changes

Fixes #688

Makes our logging logic more flexible to configure multiple loggers that write to different logfiles, so launcher.log continues to be useful as a high level overview of all update events. Detailed information is written to launcher-detail.log, which is also rotated out after 10 copies.

To enable this additional logging, this PR switches the relevant subprocess calls from check_call to check_output. It distinguishes between success & error state, but logs in both cases.

Testing

(Estimated wall time ~30 minutes, but mostly waiting.)

1. make clone this branch into dom0 and sudo dnf reinstall (or make staging if you don't have a previously provisioned environment) the freshly built RPM from rpm-build/RPMS/noarch.
2. Remove or relocate the contents of ~/.securedrop_launcher/logs so you can see the behavior with newly created log files.
3. In dom0, mkdir /tmp/sdw-migrations && touch /tmp/sdw-migrations/potato. This will force a full sdw-admin --apply run on the next update.
4. In dom0, run /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0. This will force an updater run.
5. Look at the logs in ~/.securedrop_launcher/logs
6. • Observe that launcher-detail.log contains output from sudo qubesctl --show-output state.highstate and from sdw-admin --apply
7. Modify the file /srv/salt/update-xfce-settings and insert an echo XYZZY && exit 1 statement after the set statements. This is how we'll cause all Salt runs to error out.
8. Repeat steps 3 to 5.
9. • Observe that launcher.log contains error log entries pointing to launcher-detail.log
10. • Observe that launcher-detail.log contains error logs containing the full Salt output and the XYZZY magic word we had the script insert
11. Undo your modification from step 7 to restore the environment to a working state

Checklist

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

[eloquence]

Open to a more robust solution here, of course, just don't want to write color codes to the log file.

[conorsch]

This worked quite well! Big improvement to have these details at hand, particularly after a failed run.