feat: add new metrics

[sbackend123]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

• Add transport label to libp2p created/handled connection metrics (tcp / ws / wss / quic*).
• Move /wss + QUIC classification into bzz.ClassifyTransport.
• Replace separate public/private counters with public="true|false" on handled_connection_count.
• Pre-init label series so unused transports show as 0, not missing.

Breaking changes

• created_connection_count / handled_connection_count: Counter → CounterVec.
• handled_connection_count now has labels {transport, public}.
• Removed public_address_connections_total / private_address_connections_total — use handled_connection_count{public=...} instead.
• Dashboards using count(...) as a denominator will under-count after upgrade; prefer sum by (...).

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

#5506

Screenshots (if appropriate):

AI Disclosure

• This PR contains code that has been generated by an LLM.
• I have reviewed the AI generated code thoroughly.
• I possess the technical expertise to responsibly review the code generated in this PR.

[darkobas2]

Running this on our mainnet dev canary (dev-bee-storage/bee-1, build 2.8.2-rc1-66a4ec3c). Both fixes behave: WSS now lands on its own label instead of leaking into tcp, and the zero-init gives flat lines instead of gaps. Thanks for the quick turnaround.

Live from the canary:

created_connection_count{transport="tcp"}                 55
handled_connection_count{public="true",transport="tcp"}  116
handled_connection_count{public="true",transport="wss"}    7
handled_connection_count{public="false",transport="tcp"}   2

(all other combinations present at 0)

One small suggestion: quic and quic-v1 can never be observed, since bee registers only the TCP and websocket transports (libp2p.go:358 and 381-383). Worth keeping the enum cases and the ClassifyTransport branches for the future, but dropping the two from transportLabelValues, which only drives pre-initialisation. If a QUIC transport is ever added the series will appear on first observation anyway. As it stands that's 6 of the 18 series per node that are structurally always zero.

On cardinality more broadly: this takes a node from 2 series to 18, but a bee node already exposes around 1570, so it works out at roughly a 1% increase. No concern from our side. The public label in particular earns its place, as it's the clearest inbound reachability signal we have.

[martinconic]

Could we add test cases to TestClassifyTransport and TestTransportTypePriority covering the new transport classifications? Specifically:

• Multiaddresses with the /wss component (ma.P_WSS)
• Multiaddresses with /udp/.../quic-v1 and /udp/.../quic
• Priority tests for TransportQUIC and TransportQUICV1

[martinconic]

handled_connection_count includes the public label (true/false), but created_connection_count only has transport.

Is there a reason not to include public on created_connection_count as well? In Connect(), we also have the remote multiaddr via stream.Conn().RemoteMultiaddr(), so having public on both would give symmetric visibility for outbound dials.