Dependency: Update to Prometheus 0.300.*

[ArthurSens]

Description

Supersedes #36642

This PR updates the prometheus/prometheus library in our go.mods to 0.300.* (which represents Prometheus 3.0).

It touches many go.mod files, but the Prometheus Receiver is the only component heavily affected by breaking changes.

[npordash]

The changes made to the scrape manager are a bit more involved than I expected. We'll need a new zap->slog adapter to replace the existing zap->go-kit adapter.

Help appreciated because the solution was not immediately obvious to me 😬

@ArthurSens I think you can probably use the experimental adapter in the upstream zap repo: https://github.com/uber-go/zap/tree/master/exp

[ArthurSens]

The changes made to the scrape manager are a bit more involved than I expected. We'll need a new zap->slog adapter to replace the existing zap->go-kit adapter.
Help appreciated because the solution was not immediately obvious to me 😬

@ArthurSens I think you can probably use the experimental adapter in the upstream zap repo: https://github.com/uber-go/zap/tree/master/exp

TIL, thanks for the tip! I'll try it out in the next days

[ArthurSens]

This should be ready for review! cc @dashpole

And I'm assuming we don't need a changelog entry, is that right?

[ArthurSens]

I wonder if the compliance test failures are related to Prometheus changing the default NameValidationScheme 🤔

[dashpole]

receivers::prometheus: unknown scrape protocol , supported: [OpenMetricsText0.0.1 OpenMetricsText1.0.0 PrometheusProto PrometheusText0.0.4 PrometheusText1.0.0]

Seems like the prometheus receivers' config validation changed?

[ArthurSens]

receivers::prometheus: unknown scrape protocol , supported: [OpenMetricsText0.0.1 OpenMetricsText1.0.0 PrometheusProto PrometheusText0.0.4 PrometheusText1.0.0]

Seems like the prometheus receivers' config validation changed?

Ah, maybe be related to prometheus/prometheus#15136? The changelog says

[CHANGE] Scraping: Remove implicit fallback to the Prometheus text format in case of invalid/missing Content-Type and fail the scrape instead. Add ability to specify a `fallback_scrape_protocol` in the scrape config. #15136

[dashpole]

yeah, we might need to set that in our default config

[ArthurSens]

yeah, we might need to set that in our default config

The problem is that this is a per-scrape config, it looks like we can't just add that to global and that works for every scrape... or at least I'm missing some details somewhere

[ArthurSens]

I've committed 9f01ea1 that sets Prom-text 1.0 as the default fallback to keep backward compatibility with what we had before 3.0.