Remove NewPossibleNonCounterInfo until it can be made more efficient

[zenador]

According to benchmarks, this is very inefficient for many rate queries, temporarily removing until we find a better way.

With before as without the removed code, and after as with:

goos: linux
goarch: amd64
pkg: github.com/prometheus/prometheus/promql
cpu: 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
                                                  │ BenchmarkRangeQuery_before.txt │    BenchmarkRangeQuery_after.txt     │
                                                  │             sec/op             │   sec/op     vs base                 │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-16                      15.33m ± 2%   89.57m ± 3%  +484.36% (p=0.000 n=10)

                                                  │ BenchmarkRangeQuery_before.txt │      BenchmarkRangeQuery_after.txt      │
                                                  │              B/op              │     B/op       vs base                  │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-16                     4.946Mi ± 0%   66.805Mi ± 0%  +1250.79% (p=0.000 n=10)

                                                  │ BenchmarkRangeQuery_before.txt │    BenchmarkRangeQuery_after.txt     │
                                                  │           allocs/op            │  allocs/op   vs base                 │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-16                      105.4k ± 0%   806.3k ± 0%  +665.22% (p=0.000 n=10)

[bboreham]

I compared commit 156222c, before annotations were added, with this PR, commit 7756556:

goos: linux
goarch: amd64
pkg: github.com/prometheus/prometheus/promql
cpu: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
                                                 │   before    │               after                │
                                                 │   sec/op    │   sec/op     vs base               │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   29.82m ± 3%   38.52m ± 3%  +29.19% (p=0.002 n=6)

                                                 │    before    │                 after                  │
                                                 │     B/op     │     B/op       vs base                 │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   378.8Ki ± 0%   5063.3Ki ± 0%  +1236.53% (p=0.002 n=6)

                                                 │   before    │                 after                  │
                                                 │  allocs/op  │   allocs/op    vs base                 │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   5.356k ± 0%   105.365k ± 0%  +1867.24% (p=0.002 n=6)

12x more garbage does not seem acceptable to me, so I pushed another commit which eliminates it in the case there is nothing to report.

goos: linux
goarch: amd64
pkg: github.com/prometheus/prometheus/promql
cpu: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
                                                 │   before    │               after               │
                                                 │   sec/op    │   sec/op     vs base              │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   29.82m ± 3%   31.06m ± 1%  +4.17% (p=0.002 n=6)

                                                 │    before    │               after                │
                                                 │     B/op     │     B/op      vs base              │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   378.8Ki ± 0%   368.1Ki ± 0%  -2.84% (p=0.002 n=6)

                                                 │   before    │               after               │
                                                 │  allocs/op  │  allocs/op   vs base              │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   5.356k ± 0%   5.258k ± 0%  -1.83% (p=0.002 n=6)

The 4.17% extra CPU comes from Metric.Get(labels.MetricName), which can also be eliminated, but I wanted to do the minimum to get to a reasonable state.

[zenador]

Thank you! I added a commit to further avoid creating empty annotations, and created a PR with the same changes for the new prometheus release (benchmark details there): prometheus/prometheus#13012

[charleskorn]

LGTM