feat(operator): Restructure LokiStack metrics

[xperimental]

What this PR does / why we need it:

The current implementation of the LokiStack metrics emitted by Loki Operator sometimes keeps old versions of the metrics. This leads to the metrics not properly reflecting the current state of the deployed LokiStack resources.

This PR replaces the current implementation which relied on being called by the reconciliation loop by an implementation that fetches the current information of the LokiStack resources by itself and generates metrics from that data. As the list of LokiStack resources should already be cached in the informer this should not put any additional stress on the Kubernetes API server.

Which issue(s) this PR fixes:

LOG-5253

Special notes for your reviewer:

• This completely replaces the existing metrics. Only two metrics remain:
  • lokistack_info containing information about the deployed LokiStack resources as labels (currently limited to the "size")
  • lokistack_status_condition showing the current state of the Conditions available in the LokiStack status. This setup mirrors the metrics provided by kube_state_metrics
• The alert for "needs storage schema update" has been updated to reflect the new metrics setup. I'm not aware of any other usage of these metrics so far.
• Calling List on each metrics scrape seems wasteful, but my theory is that this data should be available in the informer cache of the operator. I had a look at the apiserver metrics while running this operator version compared to a version without this change and it does look like this is true and the change does not have any effect on the apiserver.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Tests updated
• CHANGELOG.md updated

[periklis]

LGTM

[xperimental]

I wonder, if it would be a good idea to have a metric exposing the state of all conditions on the LokiStack (similar to what kube_state_metrics does for the standard types) instead of just having a metric for the warnings.

That way, we (or customers) could also produce alerts on the other conditions and, for example, automatically warn when a LokiStack fails to become ready for a while.