The logic in the keyserver's fetchDataForSocketInit method is written to handle session setting in a peculiar way. The normal session setting mechanisms rely on the result being processed by callSingleKeyserverEndpoint. When a session is set during a socket initialization, the new session is written into the result, and the caller is expected to extract it and handle it manually.

Since fetch_pending_updates is called from callSingleKeyserverEndpoint on the client, we could consider an alternative here, where fetchDataForSocketInit would only behave this way when called from an actual socket (as opposed to fetch_pending_updates). I decided it would be more simple to leave the keyserver code as-is, and to handle the received session on the client side. Open to the alternative if it's preferred.

Depends on D12387

In my test plan in D12386, the socket crash loop would never really get healed, as I had hardcoded the keyserver to timeout. (I was just confirming that fetch_pending_updates was coming in.)

Before I had D12389 in place, each fetch_pending_updates was returning an incremental update. I noticed that the incremental update was always the same (with the same updates being repeated). This was happening because the new session was not setting on the client.

After this diff, that problem went away.