Should `StreamMuxerBox` track how many "active" substreams are still around?

Description

Whilst thinking about https://github.com/libp2p/rust-libp2p/issues/2863, I noticed that it is very easy to (accidentally) circumvent the limit on inbound substreams by "leaking" them to the ConnectionHandler. We do this in various places within rust-libp2p and I am sure it happens in within code-bases of ours users too.

StreamMuxerBox already boxes up each substream as a SubstreamBox. We could extend SubstreamBox with a Weak<()> where StreamMuxerBox owns the corresponding Arc<>. This would make Arc::weak_count effectively be the count of all active (i.e. not dropped) substreams the muxer has given out.

Within Connection, we know about StreamMuxerBox so we could expose functions on it to give us the current count of active inbound and outbound streams, which would allow us to actually enforce a limit on those.

Motivation

Not limiting the number of inbound streams can cause unexpected memory and CPU growth and in the worst case, is exploitable via a DoS attack.

Downsides

Rolling out this change may negatively affect users because they will suddenly experience a limit where there wasn't one before.

Current Implementation

Are you planning to do it yourself in a pull request?

Yes.

Start by tracing StreamMuxerBox, SubstreamBox, and Connection to understand how substreams are created and retained. Determine whether active inbound and outbound counts can be exposed and used for limits; done means the proposed tracking and enforcement scope is agreed and covered by appropriate tests.