Address race conditions (including wallet encrypted with old password gets posted)

I realized that there are a few ways that race conditions could (however unlikely) get around some enforcement in our code. The most important one is after a password change, preventing a client with the old password from posting a new wallet.

• Get a new auth token using an old password, despite a password change, and use it to post a new wallet encrypted with the same old password. - See here There could be a similar race condition where a client almost posts a wallet using an auth token that gets deleted by the password change transaction, but I think the Sequence value would save us from that.
• Stay connected to a websocket initiated during a password change using an auth token that's invalidated the password change - See here - Not important yet since all we do with the websocket is inform clients about new wallet updates. But, maybe we'll do more important things on the websocket later.

Start with the password-change transaction and the wallet POST and websocket authentication paths referenced by the linked commit diffs. Trace token invalidation and sequence handling under concurrent requests; done means old-password wallet posts and invalidated websocket sessions are rejected consistently, with regression coverage for both races.