Provide connection pool metrics

[fabianfett]

As a developer using grpc-swift, I would love to instrument my outgoing grpc connections with swift-metrics. Since connections are mostly handled by grpc-swift, grpc-swift should expose those metrics.

Metrics I would like to export:

1. How many open connections in a given pool
2. How many streams on a given connection
3. Connect failures and types for a pool
4. Connect latency for a pool

Describe the solution you'd like

grpc-swift should accept a MetricsDelegate on grpc connection pool creation. If the pool state changes the delegate should be informed. The protocol could look something like this. First raw draft.

protocol GRPCChannelPoolMetricsDelegate {
  func connectionCreated(connectionID: Int, latency: Int)

  func connectionUtilizationChanged(connectionID: Int, available: Int, used: Int)

  func connectionClosed(connectionID: Int, error: Error?)

  func connectFailure(error: Error)
}

Describe alternatives you've considered

GRPC could export metrics directly to swift-metrics. However this would add a new dependency, that some adopters might not want. Further adopters may want to report the metrics differently and we want to give them options. Offering the connection metrics through a protocol should give adopters the most flexibility.

[PeterAdams-A]

Wondering if there are any other purposes these delegates could be used for - nothing springs immediately to mind but I could imagine there might be something else which users try and trigger off connection creation.

I guess this is more flexible than direct call to metrics but a bit harder for users to use.

[Lukasa]

I think we could probably offer a default solution in a separate target. That doesn't prevent us having the dependency but users who don't want it can at least avoid linking it in.

[glbrntt]

I guess this is more flexible than direct call to metrics but a bit harder for users to use.

Flexibility is a good thing here, no doubt people will want to label metrics in their own way.

I think we could probably offer a default solution in a separate target. That doesn't prevent us having the dependency but users who don't want it can at least avoid linking it in.

A "GRPCExtras" module is something I've thought about for a while. There are other general purpose things like interceptors which could be included.