Add a transport label to libp2p connection metrics (TCP vs WS/WSS vs QUIC)

[darkobas2]

Summary

The libp2p connection metrics don't expose which transport a connection uses, so there's no way to observe TCP vs WebSocket (ws/wss) vs QUIC from metrics. Adding a transport label to the connection counters would make transport usage observable.

Current behaviour

Counters such as bee_libp2p_created_connection_count, bee_libp2p_handled_connection_count, bee_libp2p_public_address_connections_total, and bee_libp2p_private_address_connections_total only carry generic labels (pod/instance/etc.) — there is no transport dimension. With WSS multiaddrs in use on some deployments, there is currently no Prometheus-visible way to confirm peers are actually connecting over WSS rather than silently falling back to TCP. Per-peer transport is only visible via the API (node /addresses and the peers/topology endpoints), which isn't scrape-able.

Proposed

Add a transport label (values like tcp, ws, wss, quic-v1) to the libp2p connection metrics — at minimum the created/handled connection counters and the public/private address connection totals.

Why it's useful

• Verify WSS-enabled nodes/bootnodes are actually serving and being reached over WSS.
• Catch transport regressions (e.g. WSS quietly failing → everything on TCP) from metrics/alerts alone, without polling the peers API.
• Build "connections by transport" dashboard panels.

Happy to help test a draft implementation.