Feat/leader election mechanism using leases

[samuel-esp]

Motivation

In order to avoid conflicts among multiple replicas when modifying resources (see #68) it is necessary to implement a leader election mechanism that elects a leader among the available replicas. The feature should be implemented using Leases (see Kubernetes Leases Explained)

Changes

• Introduced a new atomic variable inside main.go that stores the state of the replica (isLeader)
• Introduced a nested GoRoutine that manages lease lifecycle, the GoRoutine periodically checks the lease status and creates/renews the lease. When a termination signal is sent by the user or by another entity and the replica is currently the leader, it handles a graceful termination by deleting the current lease
• Implemented 2 new functions in client.go to manage lease lifecycle used by the nested GoRoutine mentioned above (CreateOrUpdateLease and DeleteLease). The first function calls the function GetCurrentNamespaceFromFile from util.go (which reads the ServiceAccount used by the downscaler) to understand the namespace where it needs to create the lease object
• Added a new Role and RoleBinding to the Helm chart that allows the downscaler to create, get, update and delete Leases inside its own namespace

Tests done

• Live Tests

TODO

• Fine Tuning Lease Renewal Time
• Unit Testing
• Further Live Testing

[jonathan-mayer]

Had a first look at the changes. What I've found is that there is actually a leader election package from k8s. I think we should use that one since it makes leader election easier and less verbose.
https://pkg.go.dev/k8s.io/client-go/tools/leaderelection

I've also found this articel which gives an example of how to use it https://dev.to/sklarsa/how-to-add-kubernetes-powered-leader-election-to-your-go-apps-57jh

[samuel-esp]

Refactored the helm chart, left open one discussion above

[jonathan-mayer]

Ok, im pretty sure we can merge after this

[jonathan-mayer]

oh i totally forgot to merge this