The existing code always uses the same selector for a given server call, even when paramOverride is specified.

This is bad practice because if we have a single server call passed to useServerCall in two places, one with paramOverride and one without, then we will end up cycling between different values passed to the selector on each invocation. That will break the selector's caching behavior.

Depends on D10679

I tested this stack using the following procedure:

1. I tested primarily on native
   1. I compiled a dev build and deployed it to an iOS simulator
   2. I created a brand new account on my local keyserver using the iOS app
   3. I ran Redux dev tools: cd native && yarn redux-devtools
   4. I added a 30s sleep at the start of resolveKeyserverSessionInvalidation
   5. I made KeyserverConnectionsHandler return null so that the socket wouldn’t automatically recover the session prior to my testing
   6. I killed the app
   7. I deleted all of the test user’s cookie
   8. I then opened the app again and navigated to a chat and sent two messages
   9. By following the Redux monitor, I was able to see that the keyserver session invalidation recovery was successful, and both messages were eventually sent after the 30s sleep concluded
2. On web, we don’t support keyserver session invalidation. However, I tested to make sure that the web app still loaded after my changes