Select flux resource for the environment

What does this MR do and why?

This MR adds a possibility to select a Flux resource within a given Kubernetes namespace in the environment settings. The list of available resources consists of the Kustomizations and HelmReleases, which are presented in separate groups in the collapsible listbox. The group is not added if there're no resources within it. The listbox is searchable. The alert is shown if an error occurs.

The selection is then computed to a path and saved in the database as fluxResourcePath. Using a path helps to get the information stored within a single database field (otherwise, we'd need to save both the name and the resource type).

The fluxResourcePath is returned within the environment query. Currently, we use a flux resource with a name equal to the environment name in the Flux sync status section of the Kubernetes overview. With this change, we would use the specified fluxResourcePath and fallback to using a name.

As the database and backend change is implemented within the same milestone, we are hiding this feature behind a flux_resource_for_environment FF for backward compatibility.

Screenshots or screen recordings

1. The field is present once the user selects a namespace.

2. The field shows previously saved fluxResourcePath

3. Available resources are presented in groups

4. A group without any results is not shown

   

5. An alert is shown if an error occurs

   

How to set up and validate locally

1. Enable feature flag:

      Feature.enable(:flux_resource_for_environment)

2. Ensure your GDK is running on HTTPS

3. Enable KAS on your GDK (steps 1-2 from the guide).

4. Visit the Project -> Infrastructure -> Kubernetes clusters page and create an agent following the instruction from the modal.

   • Select the "Connect a cluster" button
   • The modal should pop up
   • In the modal select "Select an agent or enter a name to create new"
   • You probably won't have any configured agents to show up in the list, create a new one by typing the name of your choice
   • The button should appear at the bottom of the list saying "Create agent: <your-agent-name>"
   • Select the button and click "Register" in the next view.
   • Save the token to use it in the next point.

5. Please follow points 3-8 from the guide and then the (Optional) Deploy the GitLab Agent (agentk) with k3d section to create a local cluster and connect your agent with the cluster.

6. Add the following configuration for your agent, commit the following on the default branch: .gitlab/agents/<your-agent-name>/config.yaml:

   gitops:
     manifest_projects:
     - id: <your-group>/<your-project>
   user_access:
     access_as: 
       agent: {}
     projects:
     - id: <your-group>/<your-project>

7. Follow this guide to start with the Flux

8. Visit the Environments page:

   • Project -> Operate -> Environments if the new navigation is enabled
   • Project -> Deployments -> Environments if the new navigation is not enabled

9. Create/Edit an environment using the UI, select the agent created in the previous steps and the namespace used for the Flux setup

10. Once the namespace is selected, verify the Flux resource selector is shown

11. Navigate to the Environments page, toggle the environment, wait for the Kubernetes overview to appear, and verify the Flux sync label. Take a look into the network tab of the devtools inspector and make sure the proper Flux resource is fetched.

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.

Review progress:

• UX review
• backend maintainer review
• frontend developer review
• frontend maintainer review

Related to #391581 (closed)