Provide method for sharing logs

[eloquence]

Since all of our support during the SecureDrop Workstation pilot is remote, it's important that we have an agreed upon methods for sharing logs. Methods that will currently work:

• Copying to dom0 using verbose --pass-io commands, then copying from there
• Use of a USB drive in sd-log VM

Methods that currently don't work:

• Copying directly from sd-log (restricted by us)
• Copy/paste (restricted by us)

Let's discuss if loosening any of those restrictions is appropriate, if any other methods make sense, or if not, which of the working methods we want to recommend for now.

[redshiftzero]

I think we’d want to add a command in dom0 that would tar up and encrypt the logs to FPF's communications key (analogous to the existing securedrop-admin logs in core), and then we’d want to export to a network connected VM for onionsharing/emailing/other networked method (which would require a Filecopy permissions update).

The change in #533 to add sd-log @tag:sd-receive-logs ask seems like it is a step along the path to the above, where in the interim we can instruct admins to apply the tag to an existing networked VM.

[zenmonkeykstop]

Other stuff to consider based on support experiences:

• we may want to specify a subset of VMs to collect logs from
• we may want to restrict logs submitted by keyword/regexp, or truncate logs sent
• we could consider setting up onionshare as a receiver on our side, to allow users to send logs unattended.

If we don't want to do that last point, adding an sd-onionshare VM to the mix might be worthwhile.

[eloquence]

This was partially addressed via #533, which enables users to copy files from sd-log to another VM.

[zenmonkeykstop]

This would be a requirement for broader adoption- adding a support tag to flag this and similar issues.