Small optimization to PrometheusResponse marshalling

[pracucci]

What this PR does:
I took a quick look at #3963 to see if there was any low-hanging fruit. In this PR I'm reducing the memory allocations when deserializing the PrometheusResponse. Not a big win, but still worthwhile.

name                               old time/op    new time/op    delta
PrometheusCodec_DecodeResponse-12     246ms ± 2%     241ms ± 0%   -1.95%  (p=0.008 n=5+5)
PrometheusCodec_EncodeResponse-12     314ms ±10%     308ms ± 2%     ~     (p=1.000 n=5+5)

name                               old alloc/op   new alloc/op   delta
PrometheusCodec_DecodeResponse-12     134MB ± 0%      96MB ± 0%  -28.31%  (p=0.008 n=5+5)
PrometheusCodec_EncodeResponse-12     229MB ±26%     248MB ±32%     ~     (p=0.690 n=5+5)

name                               old allocs/op  new allocs/op  delta
PrometheusCodec_DecodeResponse-12     31.1k ± 0%     31.0k ± 0%   -0.05%  (p=0.008 n=5+5)
PrometheusCodec_EncodeResponse-12     2.01M ± 0%     2.01M ± 0%     ~     (p=0.651 n=5+5)

I've manually tested it both with query-frontend and query-scheduler, adding a temporarily log to see if ContentLength is valued correctly in prometheusCodec.DecodeResponse() and it is.

Which issue(s) this PR fixes:
N/A

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[bboreham]

Good stuff!

[bboreham]

Why is this required?

[pracucci]

I don't think it's required, but I wasn't able to figure out if we may introduce any regression disabling it (the default config has it enabled). Any thoughts?

[bboreham]

I expect some clients are relying on it whether they realise it or not.
I.e. the ordering of series here maps directly to what you see in your dashboard, in at least some cases.

However we should try disabling it (in a separate change) and see if anyone notices.

[pracucci]

Opened an issue to follow up about it:
#3997