Added support for skip_authorization while applying pending promotions

What does this MR do and why?

Context

Currently ProcessUserBillablePromotionService authorises that the caller(current_user) is an admin. As part of #470661 (closed) we would allow the service to be called from a sidekiq worker in the background(which would not have a current_user). In the future, we would also trigger this same worker to be called through SCIM, LDAP, SAML flows which are considered admin flows, but would not necessarily have a current_user.

What does this MR do and why?

• This MR modifies the service to accept skip_authorization flag and allows the service to apply pending promotions even when current_user would be nil.
• It also changes member service from InviteService to CreateService as InviteService is just a wrapper on the CreateService.
• It modifies spec to add skip_authorization flow.

PS:

• this feature is behind a disabled feature flag and setting, so it isnt available on prod.
• currently this feature is only being built for self-managed

ref: #470661 (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.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Since skip_authorization flow isn't present yet, we just have to ensure existing Admin Approval flow is working as expected.

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: ( you can skip this and create MemberApproval record directly, see step 5)
   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
5. Alternatively you could create a MemberApproval Record directly in the table

   1. Open rails console

      namespace=Namespace.where(type: 'Group').first
      non_billable_user = User.non_billable_users_for_billable_management(User.all.pluck(:id)).first
      Members::MemberApproval.create(
        member_namespace: namespace,
        user: non_billable_user,
        new_access_level: 30,
        requested_by: User.active.last
      )

6. Visit local graph-iQL page
7. Get list of pending promotion users

   1. Query for same

      {
        selfManagedUsersQueuedForRolePromotion(first:20) {
          count
          nodes {
            user {
              id
              username
            }
            newAccessLevel {
              stringValue
            }
          }
          pageInfo {
            hasNextPage
            hasPreviousPage
            startCursor
            endCursor
          }
        }
      }

      1. Sample response

         {
           "data": {
             "selfManagedUsersQueuedForRolePromotion": {
               "count": 1,
               "nodes": [
                 {
                   "user": {
                     "id": "gid://gitlab/User/28",
                     "username": "i-user-0-1705348657"
                   },
                   "newAccessLevel": {
                     "stringValue": "MAINTAINER"
                   }
                 }
               ]
             }
           }
         }

8. Use the id from above list to promote the user

   1. Login as Instance Admin, and navigate to graphiQL page

   2. Use the following mutation, and variable

      mutation($processUserBillablePromotionRequestInput: ProcessUserBillablePromotionRequestInput!) {
        processUserBillablePromotionRequest(input: $processUserBillablePromotionRequestInput) {
          clientMutationId
          errors
          result
        }
      }
      
      {"processUserBillablePromotionRequestInput":{"userId":"gid://gitlab/User/93","status":"APPROVED"}}

   3. Validate you get success response

      {
        "data": {
          "processUserBillablePromotionRequest": {
            "clientMutationId": null,
            "errors": [],
            "result": "SUCCESS"
          }
        }
      } 

9. Validate that the user is now promoted in the group you queued the promotions on.
10. Validate the user is not getting returned in the pending promotion users list from above.