We have a two-part login and registration process: first the identity service, then the authoritative keyserver.

Ideally, if the first part succeeds but the second part fails, we could cache the success of the first part, and recompute it if inputs change. But I scoped that work and determined we didn't have the cycles for it right now.

An easier, more immediate solution is to simply reset the state between attempts. We'll attempt to reset the state in two places:

1. On the identity service we'll delete the CSAT, and in the case of registration delete the newly-created user entirely.
2. On the client we'll unset the currentUserInfo through either an identityLogOut or deleteDiscardedIdentityAccount action, which will result in clearSensitiveData being called due to the user ID no longer matching the one stamped on the SQLite DB.

Note – would normally put @tomek and @inka on this review, but since they're out for the rest of this week, I'm asking @varun to review.

1. Force keyserver auth to fail with this patch
2. Test new registration flow and confirm that it fails
3. Check the logs and confirm that the SQLite database was deleted
4. Stash the patch above
5. Try registration again and confirm that it works, and doesn't error due to identity already having an account with that username