Content briefly re-appears on "Files and Messages" deletion

[eloquence]

Steps to reproduce (general case):

1. Select a source and delete "files and messages"
2. Wait for the deletion animation to run its course

Steps to reproduce (reply case):

1. Send a reply
2. Very quickly delete files and messages from the source

Expected behavior:

"Files and messages deleted for this source" placeholder takes over conversation area

Actual behavior:

Conversation area content briefly re-appears, then disappears

Notes

The general case is not as consistently reproducible as the reply case. I've seen it most often early in a session.

[conorsch]

While testing #1306, I observed this behavior, and grabbed a GIF of it:

Note that I've inserted a time.sleep(5) during the refresh job as recommended in #1306, which makes it a lot easier to catch the unwanted state, with old files and messages visible again.

Will spend some more time thinking about a resolution here. After discussing briefly with @creviera, simply preserving the deletion animation until the next sync-and-redraw step would be sufficient. She also pointed out that the wait-for-next-sync behavior to redraw isn't actually strengthening the client's case for deletion having succeeded, given that deletion requests create an async job on the server. I'll take a closer look at the endpoints involved before commenting further, but am inclined to keep the GUI fix as simple as possible for the purposes of continuing with 0.5.0. See somewhat related discussion in freedomofpress/securedrop#5104 (in that a "changes" feed would help us reason about whether submissions we GET are really new, or pending removal).