New time metric aggregation layer and refactor of prometheus metrics

[adam-cattermole]

Adds a new metrics layer to the tracing configuration which times accesses to different spans.

gather accepts:

• group: the parent span to combine for
• consumer: a function to perform some kind of operation on the Timings collected for this group
• records: a list of different sub-spans of group that should be summed together

It's currently set up to sum all datastore span accesses for a should_rate_limit call

Refactor

• Moved prometheus_metrics out of the library and now defined at the server level

[eguzki]

I am trying to understand what is this doing.
I tried this branch and compared withmain. Same data at /metrics and same info from opentelemetry spans I could see in jaeger UI.

[adam-cattermole]

The primary difference is the way that those metrics are collected at /metrics @eguzki. Before the calculation was all being done inline with time instants wrapping the sections of code that access the datastore in the library. It's now been abstracted outside of the library, with all of the latency metrics being calculated through a new metrics layer instrumenting the spans. The result is two primary changes:

1. The library no longer cares or implements metrics and moves the owner of the metrics to limitador-server
2. A new tracing metrics layer that times and sums spans based on configuration, and aggregates based on the provided consumer function
   • For the time being this function is configured to sum all datastore accesses for each should_rate_limit call, and the consumer function is configured to register the total with the prometheus counter_latency metric

[alexsnaps]

Minor stuff... but otherwise LGTM