Add batch of members endpoints to fix race conditions (#2760)

[haydnli-shopify]

Summary

Implements atomic single and batch member management endpoints to eliminate race conditions when multiple automations add/remove project members simultaneously. The existing set_members endpoint required passing an authoritative list of all members, creating race conditions in concurrent scenarios.

This PR enhances the member management system to support both single-user and batch operations through the same endpoints, providing flexibility for different use cases while maintaining backwards compatibility.

Fixes #2684 (parent ticket #2742)

Changes Made

• Enhanced AddProjectMemberRequest to accept single member or array of members
• Enhanced RemoveProjectMemberRequest to accept single username or array of usernames
• Implemented add_project_members() and remove_project_members() service functions supporting both single and batch operations
• Enhanced POST /api/projects/{project_name}/add_member endpoint for single/batch operations
• Enhanced POST /api/projects/{project_name}/remove_member endpoint for single/batch operations
• Extended ProjectsAPIClient with backwards-compatible methods and new batch methods
• Comprehensive permission controls (managers/admins only, global admin privileges) for all operations
• Support for username or email lookup in both single and batch modes
• Protection against removing all project admins
• Atomic database operations eliminating read-modify-write patterns
• Comprehensive test suite covering single, batch, and edge case scenarios

API Usage

Add a single member
POST /api/projects/my-project/add_member
Body:

{
  "members": {
    "username": "john@example.com",
    "project_role": "user"
  }
}

Add multiple members (batch)
POST /api/projects/my-project/add_member
Body:

{
  "members": [
    {"username": "john@example.com", "project_role": "user"},
    {"username": "jane_doe", "project_role": "manager"},
    {"username": "alice", "project_role": "user"}
  ]
}

Remove a single member
POST /api/projects/my-project/remove_member
Body:

{
  "usernames": "john_doe"
}

Remove multiple members (batch)
POST /api/projects/my-project/remove_member
Body:

{
  "usernames": ["john_doe", "jane@example.com", "alice"]
}

Update existing member role (via add_member)
POST /api/projects/my-project/add_member
Body:

{
  "members": {
    "username": "jane",
    "project_role": "admin"
  }
}

Race Condition Fix

Previously, concurrent automations had to read and rewrite the entire project member list using the set_members endpoint, which led to race conditions and unintended overwrites. This PR introduces atomic add_member and remove_member operations that support both single and batch operations, allowing changes to apply independently and safely—even when triggered simultaneously.

[peterschmidt85]

Why not allow adding/removing a batch of users?

[peterschmidt85]

One more thought:
In order to support Join or Leave functionality, can we allow add_members and remove_members when a user adds/removes themselves to a public project – without reqing project/global admin rights.

One this is done, we can also add UI via a separate PR.

[haydnli-shopify]

@r4victor Both ticket are ready for review
PR for backend APIs: #2779
PR for UI: #2795

[peterschmidt85]

Is this PR a part of #2795? If so, should it be closed?

[haydnli-shopify]

Is this PR a part of #2795? If so, should it be closed?

Yes it is part of #2795, in order to make the code review easier, we split the PR into two different one, once this is merged, the changes in this PR cannot be seen in the UI one

[peterschmidt85]

@r4victor please confirm if this is good to merge

[peterschmidt85]

@haydnli-shopify Since we merged #2795, this PR can be closed, right?

[haydnli-shopify]

@haydnli-shopify Since we merged #2795, this PR can be closed, right?

Yes, i will close it!