Use mapped/unmapped GraphQL query filters in Agent Authorization UI

Issue: FE: Use mapped/unmapped filters in Agent Author... (#465838 - closed)

What does this MR do and why?

NOTICE This feature is behind the remote_development_namespace_agent_authorization feature flag.

It updates the workspaces/agent_mapping/graphql/queries/get_agents_with_mapping_status.query.graphql GraphQL query to use the DIRECTLY_MAPPED and UNMAPPED filters to obtain the cluster agents that are mapped or not for a given group. The UI implementation is updated to use the new GraphQL query structure.

Previous MRs in this series

• Add Map/unmap agent actions to Agent auth UI (!154303 - merged)
• Expose required parameters in Agent Authorizati... (!154341 - merged)

Upcoming issues

• FE: Display agent details in a popover (#444859)
• FE: Display a warning message when a cluster ag... (#464272 - closed)
• FE: Add "Remote Development" option to Group Se... (#444836 - 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

This MR doesn't introduce user-facing changes. It just changes the underlying GraphQL query.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Enable the remote_development_namespace_agent_authorization feature flag: rails c && Feature.enable(:remote_development_namespace_agent_authorization)

2. Follow these instructions to register two cluster agents in the gitlab-org group:

   1. Create a project in the group gitlab-org named workspaces-agents-config.
   2. Create two directories in the project's repository:
      1. .gitlab/agents/remote-dev
      2. .gitlab/agents/remote-dev-two

3. In each directory, create a file named config.yaml with the following content

   remote_development:
     enabled: true
     dns_zone: workspaces.localdev.me
     # below configuration is optional
     # they override the default values
     network_policy:
       enabled: true
       # if your GDK is configured on a public IP, you don't need to set the `egress` key in this section.
       egress:
       - allow: '0.0.0.0/0'
         except:
         - '10.0.0.0/8'
         - '172.16.0.0/12'
         - '192.168.0.0/16'
       # if your GDK is configured on a different private IP, use that in the line below.
       - allow: '172.16.123.1/32'
   # for debugging locally to increase log verbosity
   observability:
     logging:
       level: debug
       grpc_level: warn

4. To connect the cluster agents:

   1. In the workspaces-agent-config project, navigate to Operate -> Kubernetes Clusters.
   2. Click the button "Connect to cluster" and select the "remote-dev" agent. Connect the cluster and close the modal dialog. It doesn't matter if the cluster is not connected.
   3. Repeat step 2 for the "remote-dev-two" agent.

5. Open the URL http://gdk.test:3000/groups/gitlab-org/-/settings/workspaces

6. You should see the table populated with one allowed agent and two agents in the "All agents tab"

7. Click the "Allow" button. The button will transition to a loading state and the agent will become "Allowed". The button label will change to "Block"

8. Click the "Block" button. A modal dialog will appear confirming if you want to block the agent. If you click the "Block agent" button, the operation in Step 7 will be reverted.