feat: allow regex patterns in promql/aggregate keep and strip parameters

[Nepomuk5665]

Summary

This PR implements issue #509, allowing users to specify regex patterns in the keep and strip parameters for the promql/aggregate check.

Changes

• Modified AggregationCheck to accept a regex pattern for label matching instead of requiring literal strings
• Added extractLiteralLabels helper to extract individual labels from simple alternation patterns like job|instance
• Updated config validation to verify regex patterns in keep/strip lists
• For simple literal patterns, the behavior is fully backward compatible
• For regex patterns, all labels in src.Labels that match the pattern are checked

Example Usage

rule {
  match {
    kind = "alerting"
  }

  aggregate ".+" {
    keep = ["job|instance"]  # Preserve either job or instance labels
  }
}

Fixes #509

[prymitive]

I'm not sure if I understand what this is trying to achieve.
This check already allows a list of names, so making values that are regexp which allows multiple values don't add anything.

This:

  aggregate ".+" {
    strip = ["job|instance"]
  }

can already be done using:

  aggregate ".+" {
    strip = ["job", "instance"]
  }

the ticket this references asks for:

  aggregate ".+" {
    strip = ["job_.+", ".*instance.*"]
  }

[Nepomuk5665]

Thanks for the feedback! You're absolutely right - the job|instance alternation pattern was redundant since ["job", "instance"] already achieves the same result.

I've updated the implementation to:

1. Remove the extractLiteralLabels function that handled alternation patterns
2. For true regex patterns like job_.+ or .*instance.*, iterate over src.Labels and match against the regex - this enables the use case from Allow regex to keep for promql/aggregate #509
3. For literal label names (no regex metacharacters), maintain backward compatibility by also checking CanHaveLabel for labels not explicitly in the query

The new tests demonstrate the regex matching behavior:

• keep = ["job_.+"] will catch labels like job_eu, job_us being removed
• strip = [".*instance.*"] will catch labels like env_instance_id being present

[prymitive]

I don't see how this is needed.
But I also feel that it's slightly awkward for me to comment here just so that you can paste that into whatever AI models/tools you're using to generate this PR. I can ask AI myself and cut the middle man out.

[Nepomuk5665]

Hey, I apologize for the confusion and frustration. You're right to call this out.

I'm a real person (Nepomuk), but I have been using AI tools to help me find and fix bugs across open source projects. I should have been more upfront about that.

Looking at this PR more honestly - I think I misunderstood the issue #509. The original request was for regex matching against label names dynamically, but I'm not sure my implementation actually solves the real use case properly.

If you'd prefer, I'm happy to close this PR. Or if you could point me in the right direction for what the implementation should actually look like, I'd be glad to take another crack at it - but I'll make sure I actually understand the problem first before submitting changes.

Again, sorry for wasting your time with back-and-forth that wasn't productive. I appreciate you maintaining pint - it's a great tool.

[Nepomuk5665]

Closing this PR as the implementation doesn't properly address the issue. Thanks for your patience and feedback. If I have a better understanding of what's needed in the future, I may open a new PR.