Implement Watch API for Kubernetes workload types

What does this MR do and why?

This MR adds Kubernetes Watch API support for the Kubernetes workload types:

• Deployments
• DaemonSets
• StatefulSets
• ReplicaSets
• Jobs
• CronJobs.

As the Watch API will wait until it gets any data, we are doing the first request without watching and only subscribing to the watch stream only for those workload types that had data returned. After subscribing to the stream, we are getting real-time updates from Kubernetes.

This MR is a part of the Watch API effort, that is developed behind the k8s_watch_api feature flag (enabled by default). We already have support for watching the Kubernetes pods and Flux sync status. The other MR adds support for the services. With the current MR we all the Kubernetes data on the Environments page gets watched.

Screenshots or screen recordings

Screen_Recording_2023-11-20_at_22.27.53

In the video, the updates to the Kubernetes dashboard are shown while I:

• create a failing DaemonSet,
• delete it from the cluster,
• create a failing Deployment and ReplicaSet,
• delete them,
• create a successful Deployment,
• delete it from the cluster.

How to set up and validate locally

1. Visit the Environments page:

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

2. Create/Edit an environment using the UI

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. Add the following configuration inside your project in .gitlab/agents/<your-agent-name>/config.yaml for the user_access agent:

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

6. Note that the shared agents should be connected to the cluster in order to appear in the list. 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.

7. Select an agent from the dropdown in the Environments settings page and save the change.

8. Visit the Environments page and select the environment that has an associated agent.

9. Add/delete/restart workload types (Deployments, DaemonSets, StatefulSets, ReplicaSets, Jobs, CronJobs) in your cluster and verify the related data changes in real-time.

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.

Related to #422945 (closed)