Refactor metrics package with Prometheus and InfluxDB support

Split up interfaces, write vs read

The changes look large, but they're not actually that invasive. The interfaces have been split up into one write-interface and one read-interface, with Snapshot being the gateway from write to read. A ResettingTimer metric type which calculates mean, 50%ile, 95%ile, 99%ile, min, and max for timers per flush interval is added - timers are reset on every Snapshot() call. This simplifies the semantics a lot.

Example of splitting up an interface into one readonly 'snapshot' part, and one updatable writeonly part:

type MeterSnapshot interface {
    Count() int64
    Rate1() float64
    Rate5() float64
    Rate15() float64
    RateMean() float64
}

// Meters count events to produce exponentially-weighted moving average rates
// at one-, five-, and fifteen-minutes and a mean rate.
type Meter interface {
    Mark(int64)
    Snapshot() MeterSnapshot
    Stop()
}

A note about concurrency

This PR makes the concurrency model clearer. We have actual meters and snapshot of meters. The meter is the thing which can be accessed from the registry, and updates can be made to it.

For all meters, (Gauge, Timer, etc.), it is assumed that they are accessed by different threads, making updates. Therefore, all meters update-methods (Inc, Add, Update, Clear, etc.) need to be concurrency-safe.
All meters have a Snapshot() method. This method is usually called from one thread, a backend-exporter. But it's fully possible to have several exporters simultaneously: therefore this method should also be concurrency-safe.

TLDR: meters are accessible via registry, all their methods must be concurrency-safe.

For all Snapshots, it is assumed that an individual exporter-thread has obtained a meter from the registry, and called the Snapshot method to obtain a readonly snapshot. This snapshot is not guaranteed to be concurrency-safe. There's no need for a snapshot to be concurrency-safe, since exporters should not share snapshots.

Note, though: that by happenstance a lot of the snapshots are concurrency-safe, being unmutable minimal representations of a value. Only the more complex ones are not threadsafe, those that lazily calculate things like Variance(), Mean().

Example of how a background exporter typically works, obtaining the snapshot and sequentially accessing the non-threadsafe methods in it:

        ms := metric.Snapshot()
                ...
        fields := map[string]interface{}{
            "count":    ms.Count(),
            "max":      ms.Max(),
            "mean":     ms.Mean(),
            "min":      ms.Min(),
            "stddev":   ms.StdDev(),
            "variance": ms.Variance(),

TLDR: snapshots are not guaranteed to be concurrency-safe (but often are).

Sample changes

I also changed the Sample type: previously, it iterated the samples fully every time Mean(), Sum(), Min() or Max() was invoked. Since we now have readonly base data, we can just iterate it once, in the constructor, and set all four values at once.

The same thing has been done for runtimehistogram.

ResettingTimer API

Back when ResettingTImer was implemented, as part of https://github.com/ethereum/go-ethereum/pull/15910, Anton implemented a Percentiles on the new type. However, the method did not conform to the other existing types which also had a Percentiles.

The existing ones, on input, took 0.5 to mean 50%. Anton used 50 to mean 50%.
The existing ones returned float64 outputs, thus interpolating between values. A value-set of 0, 10, at 50% would return 5, whereas Anton's would return either 0 or 10. This PR removes the 'new' version, and uses only the 'legacy' percentiles, also for the ResettingTimer type.

The resetting timer snapshot was also defined so that it would expose the internal values. This has been removed, and getters for Max, Min, Mean have been added instead.

Unexport types A lot of types were exported, but do not need to be. This PR unexports quite a lot of them.

BuildOnViction / victionchain