Previously, a single user could end up in multiple batches, which would have been fine if the logic didn't assume otherwise. If a request took longer than 200ms, multiple batches would occur with intersecting sets of users, deleting promises that were then assumed to exist.
The logic now takes all "in flight" users to also not be "pending". Pending now means that the user will be processed in the next batch. "In flight" means the user is part of an ongoing batch.
This will make invalidating the userGroups cache for the user architecturally more sound (the plan is to have GroupStore hit FlairStore as opposed to Flair itself in order to invalidate the cache).
