In entitlements, we want to be able to support assign multiple users to multiple seats at once. Right now in the POST /seats endpoint, we can only assign one user to a seat. So a client has to call this endpoint multiple times in a row to assign multiple users. If they do this asynchronously, they run into a possibility for a race condition with AMS where 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

As of now, AMS does not support this sort of operation. You have to assign one seat (create one subscription) at a time. Based on the result of the linked ticket, I think entitlements will move forward in 2 possible ways:
1. if AMS adds support for batch ops:  great, this is ideal, and we add a new endpoint or update the existing POST /seats to call the batch op version of create subscriptions in AMS

2. if AMS does not add support for batch ops, or we dont want to wait: we could update POST /seats to accept a list of usernames (or new endpoint, same as above), and then call AMS for each username we want to put in a seat. This would allow the clients to at least just call one endpoint instead of having to loop thru our existing POST /seats in a sequential fashion. If we do this we should put a limit on the # of seats so we don't allow some one to try and add 100000000 seats at once or something. That would probably just break our service lol. Maybe 10 or 15 would be a good limit idk, thats me picking a number arbitrarily