Add self_managed_add_on_eligible_users query

What does this MR do and why?

This MR is a component of the MVC epic, aimed at enabling seat management for Code Suggestions on a Self-Managed instance.

Here, we are returning all eligible users for the add-on assignment: all users who are human, excluding bots, blocked, banned, and pending_approval users.

Related to #432211

In this MR, we:

• Add 'self_managed_add_on_eligible_users' to query types.
• Add the 'SelfManaged::AddOnEligibleUsersResolver' to the API.
• Add 'SelfManaged::AddOnEligibleUsersFinder' to the resolver.
• Introduce code_suggestions SaaS to differentiate between the Saas vs self-managed.

Screenshots or screen recordings

How to set up and validate locally

Currently, access is limited to admins (who can can_admin_all_resources?). Ongoing work on this GitLab issue should introduce the new policy/rule.

1. Pick or create a group and add guests, developers, owners, bots, banned, and blocked users.

2. Visit localhost:3000/graphql-explorer and add the specified query below.

3. (Optional) If you also want to test addOnAssignments (already merged and verified), you can do so by creating an add-on purchase for any group. If you don't have one, you can assign it to a namespace_id as if it's SaaS, as there is still work to be done in this GitLab issue.

GitlabSubscriptions::AddOnPurchase.create!(add_on: GitlabSubscriptions::AddOn.first, expires_on: 1.year.from_now, namespace_id: <NAMESPACE-ID>, quantity: 10, purchase_xid: 'A-12345')

• To assign users to an add-on, please refer to the instructions provided in this MR.

• addOnAssignments is either empty or returns values if any user is assigned.

• If you don't want to test addOnAssignments, keep it empty: addOnPurchaseIds: []

• Make sure that the FF hamilton_seat_management is enabled Feature.enable(:hamilton_seat_management)

Verify:

• API access is restricted to admins and the API returns all active human users, including guests, while excluding bots, blocked, banned, and pending approval users (Billable self-managed users)
• The Query is not possible if you run as an admin on a SaaS/Gitlab.com installation
  • gdk stop rails-web && GITLAB_RAILS_RACK_TIMEOUT_ENABLE_LOGGING=false PUMA_SINGLE_MODE=true GITLAB_SIMULATE_SAAS=1 gdk rails s
• The Query is possible if you run it as an admin on a self-managed instance
  • gdk stop rails-web && GITLAB_RAILS_RACK_TIMEOUT_ENABLE_LOGGING=false PUMA_SINGLE_MODE=true GITLAB_SIMULATE_SAAS=0 gdk rails s

GQL Query:

{
  selfManagedAddOnEligibleUsers(
    addOnType: CODE_SUGGESTIONS
    search: "USERNAME" # This is optional
    first: 20  # The GraphQL API mainly uses keyset pagination, adjust the number based on your desired page size
  ) {
    nodes {
      id
      username
      name
      publicEmail
      avatarUrl
      webUrl
      lastActivityOn
      lastLoginAt
      addOnAssignments(
        addOnPurchaseIds: ["gid://gitlab/GitlabSubscriptions::AddOnPurchase/<ADD-ON-PURCHASE-ID>"]
      ) {
        nodes {
          addOnPurchase {
            name
          }
        }
      }
    }
    pageInfo {
      endCursor
      hasNextPage
    }
  }
}

Performance: database: Using 101 as a limit. Typically, we aim to use it in the frontend to fetch 20 records

• The query plan for the finder execution (Without search): Cold cache: Query Plan - Without Search

• The query plan for the finder execution (With search): Cold cache: Query Plan - With Search

• The query plan for the finder execution (With search): Warm cache: Query Plan - With Search

• The query plan for the finder execution (Without search): Warm cache: Query Plan - Without Search

• The query plan for the finder execution for 20 records: Cold cache: Query Plan

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.