Allow Timer implementation to provide their Histogram to AbstractTimer

[bogdandrutu]

This PR adds a new protected constructor to AbstractTimer that accepts an externally created Histogram. The usefulness of this API is proven by changing 2 implementation Prometheus and OTLP to use the new API.

For OtlpTimer to benefit more would require a change to CumulativeTimer as well (not sure if it is worth it since OtlpTimer will need to support delta, so will most likely needs it's own count/total/max), which I did not want to do in this PR, since the benefit of providing the Histogram is already visible.

This simplifies a lot the logic of overwriting what implementation of the Histogram to use in different implementations, and removes duplicate logic of replacing the fixed bucket histogram implementation.

Signed-off-by: Bogdan Drutu [email protected]

[bogdandrutu]

Wrong japicmp report??? The super class still has it:

Comparing binary compatibility of  against 
***! MODIFIED CLASS: PUBLIC io.micrometer.prometheus.PrometheusTimer  (not serializable)
	===  CLASS FILE FORMAT VERSION: 52.0 <- 52.0
	===  UNCHANGED SUPERCLASS: n.a.
	---! REMOVED METHOD: PUBLIC(-) io.micrometer.core.instrument.distribution.HistogramSnapshot takeSnapshot()

[jonatan-ivanov]

There were a few changes around this since this PR was opened: AbstractTimer now has the same ctor that can accept a Histogram (also the OTLP registry now supports delta not only cumulative). Can this be closed?

[github-actions[bot]]

If you would like us to look at this PR, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[github-actions[bot]]

Closing due to lack of requested feedback. If you would like us to look at this, please provide the requested information and we will re-open.