Implement alloy-service resource to configure Alloy as a monitoring agent

[TheoBrigitte]

Towards: giantswarm/roadmap#3522

This PR implements the logic to configure Alloy as a monitoring agent instead of Prometheus agent.

It does

• add --monitoring-agent flag to choose between Prometheus agent and Alloy
• add logic to select monitoring agent and check for Alloy support in observability bundle version
• add Alloy service resource; which created a configmap for alloy app and a secret to be mounted by pods directly to inject values via env var
• add Alloy config files as templates
  • Alloy app helm values; with networkpolicy, clustering enabled, autoscaling enabled, affinity settings similar to Prometheus agent
  • Alloy config; with podmonitor and servicemonitor discovery, remotewrite setting
• add common labels used by both configmap and secret
• disable golang-ci lll linter (which keep complaining about long lines)

[TheoBrigitte]

Clustering works ✔️

[TheoBrigitte]

I experimented with Alloy horizontal autoscaler built into the helm chart. The autoscaler is based on memory usage and does by default scale up whenever 80% of memory usage is reached.
Autoscaling based on memory do make sense as there is a relation between the amount of time series and the memory usage: https://grafana.com/docs/alloy/latest/introduction/estimate-resource-usage/
On our side on biggest installation we see Prometheus agent using up to 10 shards and ~10GiB memory per shard. But using 10GiB. When using autoscaling the request memory setting is required, but using 10GiB would not work on installations with smaller nodes.
An idea would be to use 3GiB memory request and 300% hpa memory utilization, which would result hpa scaling up Alloy whenever it reaches 9GiB memory usage, but this still leaves cases with smaller node unresolved as pods would never be able to reach such memory usage.

Therefore I went with our current custom implementation of autoscaling based on number of metrics.

[TheoBrigitte]

Tested and working on both management and workload clusters.

[TheoBrigitte]

This was split and merged as part of other PRs:

• Move some monitoring constants and functions to common/monitoring package #65
• add support for Alloy as monitoring agent #62
• move GetClusterShardingStrategy to common/monitoring; add query argument to QueryTSDBHeadSeries #76
• remove golangci lll linter #77
• Add Alloy configuration files templates #78
• add Alloy service #80
• Wire Alloy service into the controller #81