Hermes frontend prometheus support

[moscicky]

This PR adds support for prometheus metrics in

• hermes-frontend

Prometheus support status

• hermes-api (no metrics)
• hermes-benchmark (no metrics)
• hermes-client (already supported)
• hermes-common
• hermes-consumers
• hermes-frontend (this PR)
• hermes-management
• hermers-metrics
• hermes-mock (no metrics)
• hermes-schema (no metrics)
• hermes-test-helper (no metrics)
• hermes-tracker
• hermes-tracker-elasticsearch

The downside of defining all metrics in one module is visible in this PR. If we want to register a gauge in hermes-frontend it has to be defined in hermes-commons. If it is defined there then hermes-commons needs to have a knowledge about what is being metered (which state object).

In case of this PR hermes-commons now contains ProducerMetrics which needs to be kafka-producer aware - because it is responsible for creating metrics for it.

The other example is PersistentBufferMetrics which is responsible for measuring ChronicleMap size. It must have a knowledge of ChronicleMap (which is not it's dependency) or any of the interfaces which it implements (ConcurrentMap, Map):

 public void registerBackupStorageSizeGauge(Map<?, ?> map) {
        this.hermesMetrics.registerMessageRepositorySizeGauge(map::size);
        this.meterRegistry.gaugeMapSize("backup-storage.size", Tags.empty(), map);
    }

But this raises a question: should every map be accepted?

Perhaps the gauge should be defined flexibly as

public <T> void registerGauge(T obj, ToDoubleFunction<T> f) {
        this.hermesMetrics.registerMessageRepositorySizeGauge(() -> f.applyAsDouble(obj));
        Gauge.builder("backup-storage.size", obj, f)
                .register(meterRegistry);
    }

then hermes-commons does not need to have the knowledge about state objects and it is responsbility of the caller to supply correct arguments