promql: fix info() handling of negated __name__ matchers

[aknuds1]

Which issue(s) does the PR fix:

Fixes #17931

Does this PR introduce a user-facing change?

Fix how the info() function handles __name__ matchers in the second argument:

1. Negated matchers no longer break ignoreSeries: Previously, negated matchers (!=, !~) could cause base metrics to be incorrectly added to ignoreSeries, or cause series to vanish when they matched positive matchers but were excluded by negative ones. Now ignoreSeries uses the same resolved matcher set as the info series fetch, via effectiveInfoNameMatchers.

2. Negated-only __name__ matchers select info metrics correctly: When only negated __name__ matchers are provided, a broad .+_info pattern is used to select info metrics, then the negative matchers filter them. Previously, negated matchers alone would incorrectly select non-info metrics as info sources.

3. Multiple positive __name__ matchers are supported: All positive __name__ matchers are applied with AND semantics. Previously, only the last one was kept.

[BUGFIX] PromQL: Fix `info()` function incorrectly handling negated `__name__` matchers

[zenador]

Code looks good, thank you! The previous comments can be resolved (I don't have the permissions to do so.) I just have some concerns about the defined behaviour.

1. The (invisible to user) adding of ~=".+_info" as a matcher when there are only negative matchers is surprising behaviour. I think it makes sense to do this (if the convention is for all info metrics to have that suffix and it's generally followed), but since it's surprising it needs to be clearly explained in the docs.
2. The logic for which series are retrieved as info series currently does not exactly match the logic for the ignored series. I came up with a contrived test case below to show how this could potentially be confusing. It's not a huge deal since the user can add more matchers to the first argument to get around this, but it just seems more intuitive to have the distinction between queried metrics and info series be consistent within a query (and not have any series be treated as neither or both).

load 5m
    websvc_thing{instance="a", job="1", label="value"} 0 1 2
    websvc_stuff_info{instance="a", job="1", build_data="build"} 1 1 1
    target_info{instance="a", job="1", data="info", another_data="another info"} 1 1 1

# websvc_stuff_info is ambiguously named, but when meant to be info series rather than regular metric, it works okay
eval range from 0m to 10m step 5m info({__name__=~"websvc_.+"}, {__name__=~".+_info"})
    websvc_thing{instance="a", job="1", label="value", data="info", another_data="another info", build_data="build"} 0 1 2
    websvc_stuff_info{instance="a", job="1", build_data="build"} 1 1 1

clear

load 5m
    websvc_thing{instance="a", job="1", label="value"} 0 1 2
    websvc_stuff_info{instance="a", job="1", build_data="build"} 2 3 4
    target_info{instance="a", job="1", data="info", another_data="another info"} 1 1 1

# websvc_stuff_info is ambiguously named, but when meant to be regular metric rather than info series, it doesn't work as expected currently, as it is treated as neither metric nor info series. the following is the expected result with it being treated as a regular metric, but the test fails
eval range from 0m to 10m step 5m info({__name__=~"websvc_.+"}, {__name__=~".+_info", __name__!~"websvc_.+"})
    websvc_thing{instance="a", job="1", label="value", data="info", another_data="another info"} 0 1 2
    websvc_stuff_info{instance="a", job="1", build_data="build", data="info", another_data="another info"} 2 3 4

[aknuds1]

@zenador Thank you for raising those concerns. Can you PTAL at the latest revision?

[zenador]

LGTM, thank you very much! Only thing left is to update the docs, but that can also be done separately.

[krajorama]

Stamp to unblock merge as @aknuds1 , the owner of this feature sees fit.