[UserCap BE]: Pending Member management

Why are we doing this work

In &4315 (closed), we introduced a User Cap setting for self-managed admins to prevent accidental user overages, now we are doing the same for SaaS group owners to prevent accidental overages.

This work will be broken down into the following backend steps:

• Add user cap setting
• Adding/inviting members
• Notifications
• Member management 👈 we are here
• Auto approval
• Approval Modal
• Group access modifications
• Group sharing
• UserCap availability

This issue for managing the approval process for pending members once a root group has made use of and/or reached the user cap.

Relevant links

• Epic: &5803 (closed)
• Designs: #321934[V4.png], #328680[pending.png], #321934[rt-group-owner-approved-awaiting-signup.png] (comment 594880937)

Implementation plan

• Add new individual member approval API endpoint (REST API is currently used for member management, but should consider GraphQL too)
• Add audit log entry when approving individual or all members
• Add or modify existing billable member API endpoint to list pending members for a root group
• Prevent pending members from being returned in default Billable Members endpoint* Extracted into #345694 (closed)

*This should probably be behind a feature flag to prevent confusion until the full feature is ready

Additional notes

Only group owners should have access to these changes.

For the last point in the plan (auto-approval), when a group owner disables the user cap setting, any pending members should be automatically approved so that they're no longer pending. Auto-approval has been moved into https://gitlab.com/gitlab-org/gitlab/-/issues/334381

For listing pending members, please note that new users (e.g. invited via email to a group) should remain in the pending list once approved, until they have signed up, see: #321934[rt-group-owner-approved-awaiting-signup.png] (comment 594880937)