Consider a form of "unregister"/"destroy" for metrics

[ktoso]

While reading this proposal keep the following situation in mind:

• the metrics API, being this library
• a metrics implementation, being an implementation that bootstraps the API and has some metrics handlers, and potentially a "registry" as well.
  • many metrics systems need this kind of registry; e.g. when a poll based one is implemented the describe() call has to render all the metrics the application has, to be able to do this, it needs to keep them around in a registry (e.g. prometheus or similar ones)
• some other library, that wants to offer its users metrics; it must not and can not know about the metrics library implementation

In such setup a "some other library" wants to do its best to do the right thing, but it can't know if a metrics library has a concept of lifecycle, if we don't have it in the API here. Even if most of the time it would be noop.

---

Example scenario:

• Some other library controls lifecycle of things, and it also emits metrics for them.
• It only knows about this metrics API.
• The used metrics library allocates heavy histograms and other things for each created metric.
  • It would want to free those once we know we'll never use them again; after they've been send to some gathering system.
• The other library can't call into this "release" without the shared metrics API having it in its api.

Example of metrics clients which would need this:

In prometheus metrics can unregister https://github.com/prometheus/client_golang/blob/master/prometheus/registry.go#L184 they can never be registered again with a different type, but that's fine for the use cases I am considering. Since the library always would use the same types of metrics for the same keys.

I'll PR an example which may clarify things a bit.

I would also as part of this say that we likely do not want to ship the CachingMetricsHandler as metrics implementations should implement those on their types in order to make releasing() possible / effective.

[tomerd]

now tracked in apple/swift-metrics#2