Currently, if the keyserver dequeues multiple one-time key refresh requests (from identity via Tunnelbroker) in rapid succession, it will process them in parallel.
This is bad because uploadNewOneTimeKeys relies on fetchUpdateOlmAccount, which is not architected to handle multiple parallel requests very well. Basically only one of the set of parallel requests will success per each round of fetchUpdateOlmAccount's retry. Since there are 5 rounds, this means only 5 will ever succeed, regardless of how many one-time key refresh requests are sent in parallel.
Even though these rounds don't succeed in persisting the new OTKs to the keyserver's local Olm account, they do succeed in being published to the identity service. This results in the identity service having a bunch of OTKs that are not in the keyserver's local Olm account, which leads to an olm_session_creation_failure when a client attempts to auth with that keyserver.
This diff addresses part of the issue by making one-time key refresh requests execute in sequence rather than in parallel.