p2p: limit size and rate of libp2p transport between peers

🎯 Problem to be solved

Charon accepts effectively unbounded traffic from cluster peers on its libp2p protocols. The default wire read limit is 128MB per message, and nothing bounds message rate or the number of concurrent inbound streams a peer can open: charon runs with libp2p.ResourceManager(new(network.NullResourceManager)), and yamux delegates concurrent stream limits to the resource manager.

A compromised or buggy peer can therefore make a node allocate and verify unbounded work. Local kurtosis testing also shows honest peers legitimately reaching 65-128 concurrent in-flight parsigex messages when the receiving node processes slowly, so naive limits would risk cutting off honest traffic on degraded hosts.

🛠️ Proposed solution

Introduce per-peer, per-protocol transport limits, sized from fleet data so they never touch honest traffic:

• Roll out extensive monitoring of traffic. Ship per-protocol/per-peer metrics for message sizes, read errors and handling concurrency (#4680), add them to the fleet remote-write allowlist, and collect fleet data on legitimate usage patterns.
• Limit amount of open connections per protocol. Bound concurrent inbound streams per peer per protocol (each charon message is one libp2p stream), sized from the fleet data of step 1.
• Limit size of messages per protocol. Extend the per-protocol wire read limits: #4637 caps parsigex at 32MB; priority and the DKG protocols still use the 128MB default.

Start with the existing libp2p.ResourceManager(new(network.NullResourceManager)) setup and the per-protocol wire limits, then review issues #4680 and #4637. Use fleet monitoring to establish honest per-peer message sizes and concurrency before choosing limits. Done means monitoring is deployed and allowlisted, then inbound streams and message sizes are bounded without cutting off legitimate traffic.