feat: implement gauge and counter support for OpenMetrics 2.0

[dashpole]

Part 1 of #893

Histograms and summaries are left for follow-ups.

Open Questions:

• How do we indicate that OM 2.0 support is experimental?

@ywwg @bwplotka @krajorama

[bwplotka]

For common, given v0 I would just comment on the method. If we want to be fancy we can generate comment in the exposition format too (:

Looks good so far, good start (see comments) - only question is do we iterate on this on main or some feature branch - no strong opinion, assuming commentary is clear.

Thanks

[ywwg]

looks good to me so far. My general opinion is that if some scraper asks for openmetrics 2.0, they should get it... Hypothetically I could see requiring the version number "2.0.0rc" or "1.9.9" just in case?

[dashpole]

Lots of discussion at the OM wg. We will add a NegotiateIncluding() function that takes a list of supported protocols so we don't end up with NegotiateIncludingOpenMetricsAndOpenMetrics2 ... 😆 . Then the client can decide when it wants to add support, and how it wants to gate it (behind HandlerOpts.EnableOpenMetrics?).

[dashpole]

I added a NegotiateIncluding function. I didn't deprecate the old functions (e.g. NegotiateIncludingOpenMetrics), but we can do that in a follow-up if we want to.

[bwplotka]

I think that's great, the experimental factor at this level should be a commentary.

As per discussion on Slack I think we decided to follow:

1. Exposer should eventually switch to OM2 default, but only once ready (which means we recommend opt-in "exposed protocol" option)
2. Scrapers should be opt-in for now, while OM2 is experimental