Refactors QueueExistingMemberService

Context

• As part of &13328 we are working on Adding controls for Admins/Owners to manage Billable Members promotion/addition in Groups and Projects (still a WIP feature).
• This issue deals with adding that Promotion control for the Invite New Member flow.
• When PromotionManagement conditions are applicable(code)(primarily when user is non-billable and the current change would make them billable), we want to queue the User/Member Addition/Promotion request if that addition/promotion will increase the Billable count for the SM instance (We will bring this to SaaS eventually)
  • This would mean queuing that request in a MemberApprovals table
  • Allowing Admin to view the requests and approve/reject it (being handled in different issues)

What does this MR do and why?

PS: This is a SelfManaged feature, and is still in development(WIP), so the feature-flag and settings for the feature is disabled by default.

This MR is part of a wider change, broken down for ease of review
Database changes + Model Changes to Queue Member Approvals	!154552 (merged)
Adds Finder to allow querying Nonbillable Users to be queued for promotion	!154555 (merged) (in parallel review)
Modifies existing Service to allow queuing Invited Members, (we have used the above two here)	<---- You are here
Call the service modified above through Creator Service add_members method	!156891 (merged)

This MR is built on top of the previous !154555 (merged) (in review MR), so the diff is setup against this MR for review :

• Refactors the existing QueueExistingMemberService:
  • To allow using the Service for queuing Invited Users/Members through the Invite and Member::CreatorService flow (in the next related MR).
  • To make use of the Finder for querying NonBillable Users in one query(introduced in the finder MR mentioned above), instead of individually checking billable? for each user.
  • To start saving the extra Update Params(like expires_at) (and later CreateParams) in metadata column of MemberApprovals table, to be used later when we apply the promotions.
  • To start using MemberApproval.create_or_update_pending_approval, introduced in the first MR mentioned above, for queuing Promotion request.

EE: true Changelog: changed

ref: #433179 (closed)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

1. Have an Ultimate License, and simulate Ultimate Self Managed setup (export GITLAB_SIMULATE_SAAS=0)
2. Enable Setting setting = ApplicationSetting.first; setting.enable_member_promotion_management=true; setting.save!
3. Enable FF Feature.enable(:member_promotion_management)
4. Create promotion requests:
   1. Visit any Group as an owner of that group (e.g. http://127.0.0.1:3000/groups/gitlab-org/-/group_members)
   2. try promoting a non-billable GUEST member to a DEVELOPER role (this member should be non-billable on the whole instance, i.e. have a highest role as guest, see !149094 (comment 1869616221) for details)
   3. you should see a banner saying "Role change request was sent to the administrator." — this means a promotion request has been created

Demo video of this entire flow (including the changes in the next MR) here