Consider not running new syncs if jobs from previous sync are still active

[eloquence]

We now kick off metadata syncs continuously, which is great. This also happens if we're still downloading replies/messages from a previous sync. This causes some additional complexity:

• We'll need to account for it when updating the animation state (there are two separate desired animations, one for the metadata sync portion, and one for the downloading of messages/replies);
• We'll need to account for it for changes to the status text like #775, and potential future changes like message download counts.

I'd like to discuss whether we want to preserve this behavior, or if it might be better to defer a sync until all jobs associated with the previous sync are completed.

From a user's point of view, the behavior seems to have limited value, as the user is already waiting for new content to arrive.

I realize syncs also serve the function of monitoring network state, so whether or not changing the behavior is viable may depend in part on the final logic we want to use for monitoring the network state and pausing the queues.

[sssoleileraaa]

this is somewhat a duplicate of https://github.com/freedomofpress/securedrop-client/issues/468

[eloquence]

I agree the issues are closely related, if we implemented either of the ideas in #468, this would seem to give us a straightforward way to change the behavior as described here.