Add Prometheus metrics support to the decoder

[dvdplm]

In the wake of plonky2 Issue #1513, add metrics support to the decoder as well.

• Investigate an initial set of metrics we want to track
• Add prometheus support, including configuration and sane defaults

[BGluth]

Yeah Prometheus metrics would be very nice to have (and probably low-effort to setup).

[0xaatif]

I think "decoder" in the title refers to evm_arithmetization, NOT e.g trace_decoder.

I understand we're interested in the following metrics, broken down by block, or by transaction within evm_arithmetization:

• witnesses_proved
• cpu_halts
• cpu_trace_pads
• trace_lengths

So I'm a bit skeptical of using Prometheus for the above, which I think shines with measurements like CPU % or throughput, perhaps broken down by a closed set - is this a hard requirement from ops?

Reading the prometheus docs:

When does it fit?

Prometheus works well for recording any purely numeric time series. It fits both machine-centric monitoring as well as monitoring of highly dynamic service-oriented architectures. In a world of microservices, its support for multi-dimensional data collection and querying is a particular strength.

And looking at the API for the prometheus instrumentation crate, we can

• register a metric.
• Metrics include, most relevant to the wording I've listed above, a CounterVec.

My preference is we go more "Observability 2.0", and canonical log what we need using tracing's structured logging.

[muursh]

Prometheus is a hard req.

[atanmarko]

Replaced by #797, where further discussions will follow.