Support "flag for reply" feature in client

[eloquence]

SecureDrop has a somewhat obscure but important feature called "Flag for reply".

The short version is that replies from journalists to sources are encrypted with a GPG keypair generated once per source. This keypair generation is resource-expensive, so under high load, it will be skipped for new sources to avoid a denial of service.

When this happens, the experience from the journalist's perspective is documented here. In short, for sources generated during this time need to be explicitly "flagged for reply" and wait for the source to log back in. Otherwise, the journalist cannot respond.

We need to support this workflow in the SecureDrop client. While it is rare in practice, it may occur at any time for any news organization, and news organizations may encounter it even during pilot use. So it is a must-have feature for the beta.

Design

We don't have a design for this workflow yet, so this task should be considered blocked until we have a first iteration interactive prototype.

Implementation

The client already tracks the is_flagged status per source, and the API supports flagging a source. A source only needs to be "flagged for reply" through the client if the server has failed to return a keypair for that source via the individual source endpoint.

User stories

As a journalist, when my SecureDrop instance is under very high load causing keypair generation to be suspended for new sources, I still want to be able to respond to select sources, so that I can continue to do my work.

[redshiftzero]

this should be done via adding a job that is ran in the general queue (see e.g. #412)

[redshiftzero]

in light of freedomofpress/securedrop#1584 (comment) we should implement #639 and not spend time implementing support for flag for reply in the client, so I'm closing this