Remove mimetype associations from package

[conorsch]

Description

As part of template consolidation [0], we've moved all mimetype
associations into the "securedrop-workstation-config" package [1].
The "open-in-dvm" desktop file now resides in the same package [2].

[0] freedomofpress/securedrop-workstation#471
[1] freedomofpress/securedrop-builder#190
[2] freedomofpress/securedrop-builder#198

Strictly speaking, the changes in freedomofpress/securedrop-builder#198 are sufficient to remove the duplicate files from the "securedrop-client" package. Still, as a matter of housekeeping, we should remove the files from the tarball, since we've already dropped them from the packaging logic.

Test Plan

See detailed test procedure in freedomofpress/securedrop-workstation#619

CI will fail until freedomofpress/securedrop-builder#198 is merged. We should merge that PR first, then restart CI here to confirm everything's green.

[conorsch]

Note that CI is failing here, due to the unmerged packaging logic. Happy to tack on a "temporary" commit, as in https://github.com/freedomofpress/securedrop-export/pull/65/commits, to aid in review, if desired.

[emkll]

Changes here look good to me and CI appears to be passing in the commit view

Once these changes are merged, when a user runs the updater, sd-app-buster-template will be updated with the changes introduced in this branch. sd-app-buster-template will update to securedrop-client 0.2.2 with no mimeapps.list in /usr/share/applications (removed in this PR) and mimeapps specification in home directory (requires salt state). This means that if a user manually navigates to a file, it is likely the distribution-default handler will open the file in the same VM. This will only be resolved when the end user runs the salt state against all VMs (sdw-admin --apply).
This has no impact to the client, but i think it would be prudent to ship a "safe" default in /usr/share/applications via the securedrop-config package. The challenge with that approach will be overriding this "safe" default in the viewer VMs, since they have the config package installed and they should open the files using normal associations

The client version update to 0.2.1 -> 0.2.2 will be required for template consolidation, but we can do it in a separate PR to prepare for release.

[sssoleileraaa]

The client version update to 0.2.1 -> 0.2.2 will be required for template consolidation, but we can do it in a separate PR to prepare for release.

Doing a client release in a separate PR with a tracking issue sounds good to me too. Once this is merged we can tag the client off of main and build and release.

[conorsch]

Doing a client release in a separate PR with a tracking issue sounds good to me too.

Roger that, @creviera. I've dropped the temporary commits, both the version bump & the CI quick-fix. The latter means that CI on this PR will fail until freedomofpress/securedrop-builder#198 is merged and CI is re-run here.

[emkll]

After merging freedomofpress/securedrop-builder#206, CI is now passing. Changes here look good to me. As stated by @creviera in #1160 (comment), we will open a separate PR to bump versions and update changelog, in preparation for the client release. Prior to release/final qa, nightlies should cover the dev/staging scenarios.