per OpenMetrics, the counter metric type MUST always include a _total metric point. We don't currently implement this, as Prometheus doesn't require it, but we ought to in order to be compliant.

This will probably require re-thinking the Metric trait, so that its formatting function is called with all the metrics in a family (in order to calculate a total).

The OpenMetrics standard says that certain metric types SHOULD include _created timestamps. In tinymetrics, timestamps are optional and feature-flagged, because some embedded platforms might not have an RTC.

Fortunately, this is a SHOULD in the spec (and not a MUST), but when timestamps are enabled, we should emit a _created timestamp for every metric family.

Determining a _created time is maybe a little tricky for us because we allow constructing metrics in const fn, where we can't generate timestamps. It should probably be determined the first time the metric records a value.

~~it might be desirable to have some implementation of a Prometheus Gauge metric that's actually the current rolling average of measurements over some time window.

this would be intended for use cases where, for example, you read data from a sensor every second, but Prometheus only scrapes the device's metrics every ten seconds. in this case, the scrape is going to see just the data from the most recent read of the sensor, which may not accurately reflect the state of the world --- data from the other 9 reads of the sensor in that time window is completely discarded.

in this case, it might be desirable to expose a metric value that is actually an aggregate of multiple reads, so that the value seen by prometheus is less susceptible to random spikiness in the measurement?~~

EDIT: lol, this is basically how a prometheus Summary metric is supposed to be used. we should just add support for that...