Install and configure securedrop-log as part of provisioning

[emkll]

Towards #398
As discussed in sprint planning today, and per https://github.com/freedomofpress/securedrop-log/pull/8/files
We should create salt changes to automate the configuration of securedrop-log. In order to test these changes, a dev/reviewer can install securedrop-log manually in all relevant templates, and then run a makefile target (all?) to apply the configuration changes.

sd-log

• configure /etc/qubes-rpc/securedrop.Log
• Configure securedrop-log.service
• Install redis{-server} packages
• Some way of reliably restarting the services after configuration change and reboot. Maybe packaging? systemctl enable?
• Tests to ensure configuration is correct and service is running properly

sd-{app, proxy, viewer, export...}

• populate /etc/sd-rsyslog.conf with appropriate source/destination names
• populate sdlog.conf in /etc/rsyslog.d/
• Some way of reliably restarting the services after configuration change and reboot. Maybe packaging? systemctl enable?
• test to ensure configuration is correct and service is running properly

[eloquence]

FYI, we're not currently tracking any of the logging-related changes as release-blockers -- my assumption was that worst case scenario, we can still proceed without them, using (and auditing) the existing logs instead. Defer to you & Jen, happy to promote them all to release-blocker level if we feel we absolutely must land this set of changes before the pilot.

[redshiftzero]

Let's track these centralized logging changes as a release blocker because it's going to be significantly more challenging to do remote support without this