consider iterating on behavior when sources lack keys

[redshiftzero]

Followup from #803, see @ninavizz's comment here: #803 (comment):

Upton (source) submits to NYWorld, < 60sec after loading the GetCodename page. Ely Bly at NYWorld is also working on her SD Workstation, and immediately receives Erik's tip. She will not be able to reply to him, however, until the keypair has been generated... which can take up to 60 seconds.

Upton (source) submits to NYWorld, right at the same time the server is rebooting for its nightly purge. Because of the timing, a keypair is not generated. A keypair will unfortunately not be generated, until Upton logs in again. The next day, Ely checks NYWorld's SD. She will not be able to send Upton a reply, until Upton re-checks SecureDrop.

After thinking it through, I feel the best solution for #1 is to not block Ely from replying, for the first 2 syncs after the Workstation receives Upton's submission. Instead, add a reply to the Queue and let it get sent when it gets sent. This assumes that #2 is much less likely to happen.

After 2 syncs, if a keypair is still absent, then show the below screen—as #2 is then to be the most likely scenario. On the chance that Ely sends a reply within one minute of a server reboot failed keypair, then simply bounce it with an error—and then show the below screen, with the failed reply above it.

(cross-linking with freedomofpress/securedrop#1584 server side)

[zenmonkeykstop]

Keypairs are now generates serverside at the same time as the codename, so sources should have a key available at all times. Closing this one.