operator: Add support for ruler component

[eranra]

Loki stack includes a new GA'ed component called Ruler. The Ruler component marriage metrics with logs closing the gap for customers to achieve a real consolidated observability solution. The Ruler component is responsible for continually evaluating a set of configurable queries and performing actions based on the result. There are two key types of rules that the Ruler component supports Alerting Rules and Recording Rules

Note: In addition to the direct business value, this PR also aligns Loki Operator functionality with Loki Helm functionality. Loki Helm already provides the ability to deploy the Ruler component here

With this new feature, customers will be able to selectively deploy Loki Ruler component as part of LokiStack operator deployments and be able to define a set of rules and any additional Ruler configuration needed for the Ruler component to function as described in the Ruler API documentation here.

As an alternative customers can use helm charts and not use Loki operator when the Ruler component is required.

Customer-facing API:

It is suggested that the Operator configuration for the Ruler component will be common to the configuration used by other deployments such as the Helm charts. This includes a config-map that will be created by customers. The config-map points to a yaml file holding the Ruler rules. This is the same approach used by the Helm chart solution here

Example for such ruler_rules.yaml file::

groups:
  - name: PlatformRules
    interval: 1m
    rules:
    - record: logs:openshift:platform:rate1m
      expr: |
        sum(rate({namespace=~"openshift+"}[1m]))
      labels:
        metric: "rate"
        source: "logs"

[eranra]

implementation in PR #5188

[eranra]

@periklis @Red-GV @jacobsakran please review above

[stale]

Hi! This issue has been automatically marked as stale because it has not had any
activity in the past 30 days.

We use a stalebot among other tools to help manage the state of issues in this project.
A stalebot can be very useful in closing issues in a number of cases; the most common
is closing issues or PRs where the original reporter has not responded.

Stalebots are also emotionless and cruel and can close issues which are still very relevant.

If this issue is important to you, please add a comment to keep it open. More importantly, please add a thumbs-up to the original issue entry.

We regularly sort for closed issues which have a stale label sorted by thumbs up.

We may also:

• Mark issues as revivable if we think it's a valid issue but isn't something we are likely
  to prioritize in the future (the issue will still remain closed).
• Add a keepalive label to silence the stalebot if the issue is very common/popular/important.

We are doing our best to respond, organize, and prioritize all issues but it can be a challenging task,
our sincere apologies if you find yourself at the mercy of the stalebot.

[eranra]

👍

[Red-GV]

I believe this was done with: #6195 and #5986