Optimize metadata sync frequency

[eloquence]

We now have a metadata queue (#715) and are working towards making it run reliably continuously (#672). It's currently scheduled to run once a minute. The closer we can get to real-time, the better, so let's optimize the sync frequency, potentially adding only a minimal delay between syncs, provided this doesn't cause performance issues or other unintended side effects on client or server.

[redshiftzero]

(blocked until the sync behavior stabilizes)

[sssoleileraaa]

the fix for the sdk sending authorization errors for other types of errors is in, so once #784 is merged, i think we'll be ready to optimize the client syncs

as we discussed briefly during standup, adding api calls for just getting new information (based on a last sync timestamp) will help a lot in optimizing syncs. i think we're tracking this in a nother issue. right now, we sync after 15 seconds from the completion of the last sync. we could modify this wait period to be more dynamic, like based on the length of a sync or based on whether or not we're seeing a connection timeout vs a read timeout.

[ntoll]

It appears that all the tickets required for the work on this to start have landed.

I'd like to understand what "optimized" looks like. Could it be we just sync after 5 seconds rather than 15 seconds (as now) from last sync completed -- so the client "feels" more real time. Also, what is the cost (if any) of such a sync? (Basically, do we need to do anything clever such as dynamic changes in wait period -- or is the current behaviour good enough / costs enough and we'd just be adding complexity?).

[redshiftzero]

We should test in Qubes against staging to confirm this works nicely, but I think just reducing the sync time to something as low as 5 seconds should be sufficient for this ticket since we wait to start the next sync until the completion of the one prior.

[redshiftzero]

This is related to #800 since we need to prevent starting duplicate message/reply downloads if we reduce the sync time

[redshiftzero]

well apparently we already have a uuid stored as an attribute on every ApiJob except the metadata sync, so we can make use of that to prevent adding duplicate jobs. Wip in https://github.com/freedomofpress/securedrop-client/compare/sync-time-speed (cross-linking #116 which would also be closed by this)

[eloquence]

Closing this stale issue; the 15 second sync we've landed on has worked well since then; we may revisit sync behavior in context of moving to an API based on a changes feed, rather than a full download of all metadata on each sync.