fix(approx_topk): Map approx_topk operation in all cases

[benclive]

What this PR does / why we need it:
Calling approx_topk on some types of queries was causing a panic in the querier.

• This is because the approx_topk operation is not supported on the querier and can only be executed on the front-end and MUST be rewritten.
• In some operations, the approx_topk was not considered shardable and we did not rewrite this query. Specifically, comparison operators are not considered shardable and so skip the rewriting & cause the queriers to panic.

This PR does 2 things:
1. Adds comparison operators to "shardableOps" map. This means they will be considered shardable and trigger the sharding logic. This is the same as the existing arithmetic operators - we don't have any special logic for them, though it doesn't really give us any benefit either. Removed because it not clear this is still correct.
2. Adds a catch-all for the approx_topk operation. If the inner query is NOT shardable, we still rewrite the logic as if there are 0 shards and send the inner query to the querier. This won't panic but it shouldn't be happening a lot so I added an error log.

I added tests for these cases & did some local testing to check they behave as intended.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[jeschkies]

Are we sure these are shardable? Is this an orthogonal change to the above?

[benclive]

As far as I understand, we should treat them the same way as the arithmetic operations above. There's no special logic for those operations, they just get mapped to queriers and combined as usual.
I don't think sharding a approx_topk query containing a comparison will change the result, as far as I can see, though I don't have any proof beyond the existing tests that it is valid to do so.
If you prefer I can remove this change and those types of queries will fall into the "not shardable" logic instead. I've tested it locally and it does seem to give correct results - WDYT?

[jeschkies]

Hm, so I'd push the operator don to each shard because it's filtering out the metrics. Does that makes sense? As in:

count_over_timer({...}[...]) > 0

should be

downstream<count_over_timer({..., __shard__=0}[...]) > 0>
++ ...
++ downstream<count_over_timer({..., __shard__=n}[...]) > 0>

and not

(downstream<count_over_timer({..., __shard__=0}[...])> 
 ++ ...
 ++ downstream<count_over_timer({..., __shard__=n}[...])>
) > 0

I think sharding these is a little more evolved and should be a separarte PR.