Many test failures in dom0 due to recent sd-app changes

[eloquence]

Steps to reproduce

Run make test in your dom0 checkout with a recently provisioned SecureDrop Workstation using latest nightlies.

Expected behavior

Tests pass

Actual behavior

Lots of test failures, mainly due to the string "Setting /usr/bin/securedrop-client to enforce mode" appearing in command output. Example:

FAIL: test_mimeapps (test_app.SD_App_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/erik/securedrop-workstation/tests/test_app.py", line 30, in test_mimeapps
    self.assertEqual(results, expected_results)
AssertionError: 'Setting /usr/bin/securedrop-client to enf[46 chars]top;' != '2 \n    295 open-in-dvm.desktop;'
+ 2 
- Setting /usr/bin/securedrop-client to enforce mode.
-       2 
      295 open-in-dvm.desktop;

Explanation

Nightlies broke on October 5 and were just fixed today, so we did not notice this earlier. freedomofpress/securedrop-client#1153 changed the logic for updating the QUBES_GPG_DOMAIN to also invoke sudo aa-enforce /usr/bin/securedrop-client. That command produces the aforementioned output. Because this is done in profile.d, the command runs on every qvm-run sd-app command from dom0, which breaks the sd-app tests.

We can redirect the aa-enforce output to /dev/null, which would fix most of the tests, but that assumes we really want to run aa-enforce this frequently. In any event, this test directly reads the contents of the file that's been modified as part of freedomofpress/securedrop-client#1153, and will still need to be updated.