If we ever receive a user cookie, we can consider the keyserver session to be recovered.

By flipping sessionRecoveryInProgress to false, we tell CallKeyserverEndpointProvider to flush all waitingCalls using the new cookie.

It doens't matter if the new cookie came from the keyserver session recovery or not. If the keyserver session recovery is still in progress, when it concludes it should be ignored by invalidSessionRecovery.

Additionally, if the session is invalidated, we can consider the recovery to be failed and concluded.

Depends on D10948

1. Test successful session invalidation in single keyserver world
   1. I prevented the Socket from rendering by adding a return null line before the other returns in KeyserverConnectionHandler. This avoided the Socket triggering session recovery.
   2. I started the iOS simulator and logged in using a test user.
   3. I opened the Redux Dev Tools
   4. I deleted the test user's cookie from the MariaDB database: DELETE FROM cookies WHERE user = 6390578 AND platform = 'ios'
   5. I sent a message as the test user
   6. I confirmed that session recovery was triggered in the Redux dev tools (and through some console logs)
   7. I repeated the process above several times to make sure it consistently worked multiple times in a single run
   8. I confirmed that the message was delivered "transparently" (without any visible issues, or evidence of session invalidation)
2. Test failed session invalidation in single keyserver world
   1. I ran through the above test, but I hacked legacy-recover-keyserver-session.js to use the wrong password so the session recovery would fail
   2. I confirmed that I was logged out, and that an alert appeared explaining that my session was invalidated
3. Test logging out during session recovery
   1. I triggered an infinite loop of session recoveries by running through the above test, but swallowing the SET_NEW_SESSION
   2. I logged out of the app
   3. I confirmed that the session recovery loop stopped, and that I was logged out successfully