star/unstar: apply change locally then apply to server

[redshiftzero]

we should modify the starring logic to apply change locally and then push to server, following decision in #51:

while starring or unstarring, the in-progress UI should prevent the user from sending another API
request to star/unstar (these could get processed out of order and they do not commute)
if success: UI change stays
if failure: remove star (for starring case, add star for the unstarring case, mark source not flagged for the flagging a source case) locally, report error to the user, update UI to reflect local db
if failure due to 404: sync API, source is deleted, report the source was deleted (this delete scenario is why we should avoid enqueuing idempotent changes until we succeed, we can enter a deadlock state if the source was deleted on the server)

wip in c52d6a4

User story: As a SecureDrop journalist, I want my changes to appear rapidly in the UI so that I don't wonder if something went wrong

[ninavizz]

Adding to #650

[eloquence]

As far as I can tell, starring changes are applied immediately from the user's point of view; is this still an issue?

[redshiftzero]

the star updates locally though if you close the client before the server job completes, the state will revert when you open the client again and log in. Choices are:

• only update UI when server updates, implement "This may take a while, and it may fail server-side" <— Surfacing such things to users #650, the user will not see surprising state changes.
• leave the logic as is to update immediately but indicate via "This may take a while, and it may fail server-side" <— Surfacing such things to users #650 that it may take some time to be confirmed server-side.
• prevent user from closing client if operations are in progress.
• implement persistent queue, starring attempts resume on user's next login (problem with this is that the next user to sign in might be a different journalist).

I'm going to close this and we can show something in the UI (#650) to indicate that the state may either take some time to display or revert if unconfirmed, depending on whatever we decide we can modify the logic here.