Feat: Retry When Detecting Concurrent Updates

[samuel-esp]

Motivation

When the list of resources to be processed is large (e.g., 2000+ resources), the KubeDownscaler algorithm may take up to half an hour to complete its run. This can lead to the following scenario:

1. All resources are initially retrieved.
2. As KubeDownscaler processes each resource, a resource that was previously retrieved may be modified by another entity (such as an HPA, Keda, or through manual intervention).
3. When KubeDownscaler attempts to process this modified resource, it encounters the following error: "the object has been modified; please apply your changes to the latest version and try again".

Even if KubeDownscaler will process the resource again during the next iteration, this could be a blocking behavior when --once argument is enabled on a large cluster. It could lead to some resources not being correctly processed

Changes

Added a new argument --max-retries-on-conflict that allows the user to specify how many times the resource update should be retried before moving on to the next resource

Tests done

• Unit Tests
• Built custom image and tested on a test cluster

TODO

• I've assigned myself to this PR

[JTaeuber]

Minor change for consistency. Other than that LGTM

[JTaeuber]

LGTM