docs(readme): add architecture diagram

[cfm]

Status

Ready for review

Description

@deeplow and I have walked through the log/ portion of this repository and mapped out:

• what spawns what services;
• what triggers what RPCs; and
• what reads/writes from/to what.

It should be descriptive and uncontroversial, except that we couldn't account for:

1. securedrop-log, which nothing in either securedrop-client or securedrop-workstation appears to invoke; or
2. securedrop_log, which nothing in either securedrop-client or securedrop-workstation appears to load.

Are they remnants of an earlier implementation, before the securedrop-redis-log → securedrop-log-saver buffering pipeline and the sd-rsyslog → qrexec securedrop.Log RPC?

[legoktm]

It should be descriptive and uncontroversial, except that we couldn't account for:

1. securedrop-log, which nothing in either securedrop-client or securedrop-workstation appears to invoke; or
2. securedrop_log, which nothing in either securedrop-client or securedrop-workstation appears to load.

I've discovered this before as well, and came to the same conclusion. If you look at the first commit to securedrop-log (9ff16b6), the original idea was that clients directly log to the VM via a custom log handler, but that was dropped later on in favor of rsyslog (see freedomofpress/securedrop-log#7 and 29c1cf7), but the old approach was never deleted.

[legoktm]

Also: this is great, will make it very easy to visualize the proposed changes in #1719 once we get there :)

[cfm]

Thanks for the reassuring confirmation, @legoktm. I've removed the [WIP] prefix here, so now it's truly ready for review. I've deliberately left these in, as an annoying visual TODO for #1998:

securedrop-client/log/README.md

Lines 40 to 41 in a804886

	securedrop-log???
	securedrop_log??? -.qrexec.-> securedrop.Log

[legoktm]

LGTM, will hold off on merging so @deeplow has the chance to review too.

[legoktm]

(gonna land this, we can always make follow-up changes if it's not accurate)