Prometheus-exporter should permit configuring a `Gauge` to be exported as a `Counter`, or applying a conversion factor to a `Counter`

[BatmanAoD]

Since metrics-rs "counters" are exclusively integers, there's no way to natively represent the equivalent of a Prometheus floating-point "counter." This has been brought up before (#367, #599) with users requesting to change this aspect of metrics itself, but I don't see a suggestion for handling this as a configuration on the exporter, so I'm writing one.

The idea is that the user would record floating point "counter" data using the Gauge type, then configure the Prometheus exporter to export those specific Gauges to Prometheus as Counter (so that Prometheus interprets them correctly).

This has a few disadvantages compared to #599:

• It would be entirely the user's responsibility to ensure that the Gauge value is never reduced. One way to mitigate this disadvantage would be to provide a "wrapper" type over Gauge, something like FloatingPointCounter, that would require the inputs to be non-negative. This would basically be the same as providing a new metric type, except that it would be restricted to the metrics-exporter-prometheus crate.
• There may be an additional complication in how rollover would work, but to be honest I don't actually know how client-libraries are supposed to handle Counter roll-over.
• As pointed out in is counter macro supports floating point values? #367, OTEL also supports non-integer counters, and this suggestion doesn't benefit other metric-exporting crates unless there's a way to share the solution between them.

[BatmanAoD]

...actually, there's another approach, so I've amended my title.

The Counter could be configured to be exported with some conversion factor to apply, so that the raw u64 value maintained in the Counter object is first converted into a floating-point value and divided by the conversion factor before exporting to Prometheus. This would enable e.g. tracking time in nanoseconds but exporting as (floating point) seconds.

(The conversion arithmetic would need to be carefully written to ensure that precision isn't lost for large Counter values, of course.)