Right now, in entitlements POST /seats a client can only add one user to a seat. This means they have to call this endpoint multiple times for multiple users. If they do this asynchronously, they run into risk of hitting a race condition with AMS. An example of this would be: 2 requests, a and b, fire at once. The quota version will be retrieved for request a, then request b, then request a will update the quota version, then request b will fail to update the quota version because its current version is out of date. So right now clients have to make these multiple requests synchronously. Slack thread for an example of this happening: https://redhat-internal.slack.com/archives/C04MZT67Y9M/p1696267201240929?thread_ts=1696256860.529229&cid=C04MZT67Y9M

A work around for this would be to allow clients to add multiple users to seats at once. So instead of POST /seats accepting just one username, it accepts a list (or a new endpoint does). Then, depending on the solution with AMS, we either utilize a new batch operation methods of creating subscriptions, or call AMS for each username in the list.

Note the race condition will still technically exist by design. To fully avoid this, we would have to either implement retry logic in entitlements to check for the race condition, or AMS would have to provide db locking or something around the quota version (probably way more complicated). But performing batch ops would be nice regardless of this to 1) reduce likelihood of hitting this race condition, 2) reduce # of requests to entitlements for assigning users to seats. See the "relates to" ticket for info on how we can avoid this