Don't return incorrect position information from annotations generated by sharded query legs

[charleskorn]

What this PR does

This PR fixes an issue where annotations could be returned to a user with incorrect position information if the query is sharded and the sharded legs generate annotations.

For example, running the query avg(rate(up[1m])) can produce two annotations:

• PromQL info: metric might not be a counter, name does not end in _total/_sum/_count/_bucket: "up" (1:10)
• PromQL info: metric might not be a counter, name does not end in _total/_sum/_count/_bucket: "up" (1:12)

...but up appears at position 10 on line 1, so the second annotation at position 12 is misleading or confusing. It comes about because avg(...) is rewritten as sum(...) / count(...) for sharding and the second annotation is generated by queriers for the sharded count(rate(up[1m])) legs.

Another example: running the query ceil(sum(rate(up[1m]))) returns PromQL info: metric might not be a counter, name does not end in _total/_sum/_count/_bucket: "up" (1:10) (because sum(rate(up[1m])) is what is run in queriers), but up appears at position 15.

We already remove position information for annotations generated by the parent query (ie. the one run in query-frontends to combine the results of the sharded legs), so this PR does the same for annotations from sharded legs.

Which issue(s) this PR fixes or relates to

Related to #9138

Checklist

• Tests updated.
• [n/a] Documentation added.
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX].
• [n/a] about-versioning.md updated with experimental features.

[jhesketh]

LGTM. Have you considered how difficult it would be to re-write/re-calculate the positions post-shard? Either way, better to not have them than have incorrect ones for now.

[charleskorn]

LGTM. Have you considered how difficult it would be to re-write/re-calculate the positions post-shard? Either way, better to not have them than have incorrect ones for now.

I started looking into it, and it would be quite involved - certainly not impossible, but likely not worth the effort for most queries where the thing each annotation is referring to is usually clear.