Throttle handling of shoot events in the frontend

[holgerkoser]

What this PR does / why we need it:

Throttling Shoot Events in the Frontend

In scenarios where we manage extensive lists of shoot clusters, each modification to any shoot cluster was previously dispatched individually to the frontend via a socket.io connection. This process led to the constant re-sorting and complete replacement of the list in the store. Each of these socket.io events encompassed the full shoot manifest. With the introduction of this PR, we have streamlined the process: now, only the UID of the altered shoot cluster is transmitted. These modified UIDs are accumulated in the store and are synchronized at maximum intervals of 0.2 to 30 seconds. This synchronization is also executed through a socket.io message. On the backend side, the current UIDs are fetched from the watch cache. A check is performed to ascertain whether the socket has joined a room associated with the relevant namespace. The cluster manifest is then relayed to the frontend only if this condition is met. Subsequently, in the frontend, all modifications are processed within a shootStore.$patch function. This ensures that the list is rendered efficiently, avoiding multiple re-renderings.

An experimental configuration option has been introduced to fine-tune the throttle delay per cluster. This option, found under Values.global.dashboard.frontendConfig.experimental.throttleDelayPerCluster, allows administrators to set the base number of milliseconds delay per cluster. This delay dynamically adjusts the synchronization throttle based on the number of active clusters, optimizing performance and resource utilization in environments with a varying number of clusters.
Note: As this is an experimental feature, its behavior and effectiveness are subject to evaluation and potential future adjustments.

Removal of the key property in the g-shoot-list-row component

By removing the key property, instances of the g-shoot-list-row component, along with all its children, were no longer destroyed and recreated each time the shoot list was paged or re-sorted. This change has significantly reduced excessive memory turnover, which previously overwhelmed the garbage collector."

Experimental Feature: Control of watch cache for list shoots requests

This feature allows fine-tuning the behavior of how list shoots requests are handled in terms of caching.
Note: As this is an experimental feature, it is subject to change and may not be stable.
Possible values for Values.global.dashboard.experimentalUseWatchCacheForListShoots are:

• never: All list shoots requests are directly forwarded to the kube-apiserver without using the watch cache.
• no: The watch cache is not utilized by default. However, clients can opt-in to use the watch cache on a per-request basis.
• yes: The watch cache is used by default for serving list shoots requests. Clients can opt-out if they require data directly from the kube-apiserver.
• always: All list shoots requests are served from the watch cache, reducing the load on the kube-apiserver.
  The default value is currently never.

Reduce network traffic

The synchronization of updated shoots is no longer performed when the browser tab is in the background. This significantly reduces network traffic when users have multiple tabs open or leave them open overnight.

CPU and Memory comparison

When all projects were displayed in the cluster list, the CPU usage consistently exceeded 98% (Process ID 89141). Following the modification, the CPU usage dropped to less than 0.5% (Process ID 88943). Memory usage has also decreased, as previously, memory allocation occurred more rapidly than garbage collection could free it.

Performance comparison

Before the Change

Update component instance was effectively being called constantly, as events that altered the shoot list were being processed continuously.

An instance update took 2.41 seconds. The vast majority of this time was spent sorting and filtering the shoot list.

Filtering was being performed even though no filter was specified. This took about 2.06 seconds.

After the Change

The update of the shoot list is now dynamically throttled and occurs much less frequently.

The instance update now takes 150 ms.

The order of sorting and filtering has been reversed, and the filtering has been moved to its own getter to automatically cache the filtered items. Filtering is only performed when a filter is specified. Otherwise, the items are returned directly. The sorting, especially the retrieval of sorting values, has been optimized, making it significantly faster.
Sorting by e.g. ISSUE SINCE now takes approximately 10 ms and can be further optimized if necessary.

Network activity comparison

The initial loading of all cluster has also been improved by serving the data from the gardener dashboard watch cache.

Before the Change

Previously, loading approximately 3200 clusters from the kube-apiserver through the dashboard backend into the browser took over 14 seconds. The amount of data transferred was 7.8MB.

After the Change

Now, loading approximately 3200 clusters from the watch cache in the dashboard backend into the browser takes about 700 ms. The amount of data transferred has been reduced to 3.0MB.

Which issue(s) this PR fixes:
Fixes #1636 Fixes #1644 Fixes #1653 Fixes #1654

Special notes for your reviewer:

Release note:

An improvement in performance and memory usage on the shoot list has been achieved when a large number of clusters are present. In the past, under heavy load, there were repeated instances where the dashboard became unresponsive due to very high memory consumption. This has been achieved by implementing the following two changes:
* Throttling of shoot events in the frontend. 
  Now, only the `uid` of the modified object is sent to the client, coupled with periodic synchronization of associated shoots.
* Removal of the key property in the `g-shoot-list-row` component 
* Improved performance of sorting and filtering implementation
* Faster response times for list shoot request (experimental: must be enabled by an operator)
* Reduced network traffic for invisible browser tabs 

Experimental Features:
* Enhanced Watch Cache Control for List Shoots Requests. 
  We've introduced a new feature to fine-tune caching behavior for list shoots requests. A new configuration option, `Values.global.dashboard.experimentalUseWatchCacheForListShoots`, has been added to the `gardener-dashboard` Helm chart. This allows for more precise control over caching with four settings: `never`, `no`, `yes`, and `always`. By default, this is set to `never`. As an experimental feature, we welcome feedback and suggest caution in production environments.
* Fine-tune the throttle delay per cluster.
  This option, found under `Values.global.dashboard.frontendConfig.experimental.throttleDelayPerCluster`, allows administrators to set the base number of milliseconds delay per cluster. This delay dynamically adjusts the synchronization throttle based on the number of active clusters, optimizing performance and resource utilization in environments with a varying number of clusters.

[petersutter]

/lgtm

very nice improvement!! 🚀