Support logout via /logout endpoint

[eloquence]

Once the API logout endpoint is implemented on the server-side (freedomofpress/securedrop#3933), we need to support in the client. Using the /logout endpoint will ensure that API tokens are blaclkisted, mitigating risks of token re-use by an attacker.

[redshiftzero]

@emkll and @creviera and I discussed this today and resolving this in a way that is not confusing to the user is a little more complicated than first expected (my bad @emkll, I thought this would be a smaller issue). I'm commenting here instead of pull #418 because we might want to merge it or something very similar (e.g. running lines 629-631 here in the failure method also) as a first iteration but leave this issue open until we get the exact behavior we want (since that behavior is likely blocked on improved queue behavior, specifically #379 #384 #410). Here are some requirements I think we want here:

1. once the user clicks logout, we should no longer allow network actions to occur EXCEPT the logout action (this is not quite what Call logout endpoint when signing out in the client #418 is doing, since the metadata sync will continue, message/reply download jobs will continue to get added to the queue, and the queue itself will continue processing until we confirm successful token invalidation)
2. since the logout action can fail on the server side, regardless of the server state we should immediately have the auth state in the client go to the logged out state (this prevents e.g. even more jobs from being added to the queue), except for the pending token invalidation. this is basically what the suggestion here (comment in #379) is suggesting so we should implement that behavior generally for queue actions and not just for the logout.
3. we do everything we can client side to ensure that tokens get invalidated. the best we can do here if the logout server action continues to fail is to persist the token invalidation job and attempt it again when network recovers / auth returns. This is worth debating, as this may increase risk as we'd need to store the token client-side in order to attempt to invalidate the token again. Note that they expire anyway within 8 hours.