[SPIKE] Identify strategy to manage seat assignment at primary integration points

Background

This issue is part of [Seat Assignment Model] Backend Foundation (&16982)

In #565402 (closed) the following locations were identified as primary integration points requiring seat assignment coverage:

Service Layer Integration:

1. Members::CreateService#after_execute
2. Members::UpdateService#post_update
3. Members::ApproveAccessRequestService#after_execute
4. Members::DestroyService#after_execute

SCIM Service Integration:

1. Gitlab::Scim::Group::ProvisioningService#create_user_and_member
2. Gitlab::Scim::Group::DeprovisioningService#remove_group_access
3. Gitlab::Scim::Group::ReprovisioningService#add_member

SAML Integration:

1. Gitlab::Auth::GroupSaml::MembershipUpdater#add_default_membership
2. SAML group sync worker completions

LDAP Integration:

1. Gitlab::Auth::Ldap::Sync::Group#add_or_update_user_membership

Model Callback Integration:

1. Member#refresh_member_authorized_projects
2. Member#after_accept_invite
3. Member#after_accept_request

Proposal

In this issue we want to explore strategies to manage seat assignment at these primary integrations.

Result

Agreed upon strategy to manage seat assignments at these primary integrations, in consideration for future extension.

Considerations

• Each location should trigger seat assignment creation/updates through a centralized service to ensure consistency.
• Implement idempotent operations to handle duplicate triggers.
• Consider async processing for bulk operations to avoid performance impacts.
• Ensure proper error handling and rollback mechanisms for failed seat assignments.