metrics: Expose litep2p metrics in an agnostic manner

[lexnv]

This PR optionally exposes litep2p metrics in an agnostic manner.

API Design

Litep2p supports at the moment the following primitives to register and operate on metrics:

/// A registry for metrics.
pub trait MetricsRegistryT: Send + Sync {
    /// Register a new counter.
    fn register_counter(&self, name: String, help: String) -> Result<MetricCounter, Error>;

    /// Register a new gauge.
    fn register_gauge(&self, name: String, help: String) -> Result<MetricGauge, Error>;
}


/// Represents a metric that can only go up.
pub trait MetricCounterT: Send + Sync {
    /// Increment the counter by `value`.
    fn inc(&self, value: u64);
}

/// Represents a metric that can arbitrarily go up and down.
pub trait MetricGaugeT: Send + Sync {
    /// Set the gauge to `value`.
    fn set(&self, value: u64);

    /// Increment the gauge.
    fn inc(&self);
...
}

Around these primitives, substrate can expose prometheus metrics, and if need be update seamlessly to other metric crates (like prometheus-client).

Metrics Exposed

The exposed metrics inform the user about the state of litep2p components (like kademlia number of store elements, identify negotiating substreams etc) and help developers detect abnormal behavior (like memory leaks / unbounded growth / stalls in some protocols).

Transport Manager

• number of incoming connections
• number of outgoing connections
• number of opening errors
• number of managed peers
• number of pending connections

Transport Layer (TCP + Websocket)

• number of pending inbound connections
• number of pending open connections
• number of raw unnegotiated connections
• number of pending substreams

Kademlia

• number of total peers
• number of engine running queries
• number of executor queries
• number of memory store records
• number of memory store local providers
• number of memory store providers
• number of memory store provider refreshes

Identify / Ping

• number of total peers
• number of pending inbound substreams
• number of pending outbound substreams

Request Response Protocol

These metrics are exposed for every req-resp protocol.

• number of connected peers
• number of pending dials
• number of pending inbound substreams
• number of pending inbound requests
• number of pending outbound
• number of outbound cancels
• number of pending outbound responses

Notification Protocol

These metrics are exposed for every notification protocol.

• number of connected peers
• number of outbound initiated handshakes
• number of outbound substreams
• number of validation
• number of ready substream handshakes
• number of timers

Dashboards

Review notes: Metric traits are define in src/metrics.rs, they should give enough background for the metric registration / update that is happening in the rest of the code