Add infrastructure for Subspace networking metrics.

[shamil-gadelshin]

This PR adds the infrastructure code for custom DSN metrics. It follows a discussion from this PR: #2280

The PR exports a single metric (established connections) for demo purposes.

Code contributor checklist:

• I have read, understood and followed contributing guide

[nazar-pc]

I don't think I fully understand why we need external and internal metrics separation. In fact I'm not sure why those are even exposed as networking types, I would have expected optional Registry to be provided as a construction argument for networking to register whatever metrics it needs just like it is with libp2p itself.

And I'd like to emphasize that none of this is about networking metrics, we need more farmer and other metrics too, so changes should be done with that in mind.

[shamil-gadelshin]

AFAIK, the Registry struct we use doesn't support clone() and must be operated using &mut which will leak the lifetime up from the first (lowest) usage of the registry across the library stack which will be very inconvenient. it's easier to pass preconfigured structs here. I would also prefer simplifications and am open to suggestions.

For example, we could invert the dependencies and return Registry along with node and node_runner with downsides starting with "incorrect abstraction level". Another option would be exposing "Registry" as a detachable property for &mut Node variable (node.registry.take()). Both options could resolve your request but I'm not sure they are better solutions.

[nazar-pc]

AFAIK, the Registry struct we use doesn't support clone() and must be operated using &mut which will leak the lifetime up from the first (lowest) usage of the registry across the library stack which will be very inconvenient. it's easier to pass preconfigured structs here. I would also prefer simplifications and am open to suggestions.

Yes, you send &mut Registry and instantiate whatever structs you need internally for specific metrics, but it is an internal implementation detail. This is how libp2p works, how Substrate works (modulo the fact that they have a different library) and how our code should work as well IMO. In Pulsar/Space Acres we will instantiate registry at the very top of the stack and pass it down for all the various components to add theirs specific metrics to it.

For example, we could invert the dependencies and return Registry along with node and node_runner with downsides starting with "incorrect abstraction level". Another option would be exposing "Registry" as a detachable property for &mut Node variable (node.registry.take()). Both options could resolve your request but I'm not sure they are better solutions.

This is backwards if we are talking about generic metrics that networking contributes to rather than networking metrics that others are using by accident.

We can wrap Registry in Arc<Mutex<Registry>>, but I don't think that'll be necessary.

[shamil-gadelshin]

Yes, you send &mut Registry and instantiate whatever structs you need internally for specific metrics...

It makes sense. I misunderstood you then.

I think the constructor() could accept &mut Registry and create both metrics types internally. That would be an improvement.

[nazar-pc]

Functionality-wise looks fine, some suggestions for renaming/refactoring.

[nazar-pc]

I'll squash-merge once CI passes