transport tests: many streams and lots of data

[MarcoPolo]

Related to #2194.

There is a failure with mplex that I haven't spent time yet debugging. If it's not obvious, I'd suggest we fix this in parallel with the webrtc work. Meaning merge this as is and have an issue to fix it soon.

[MarcoPolo]

Windows stalls with webtransport:

2023-05-16T19:50:01.2122591Z === RUN   TestManyBigPings/WebTransport
2023-05-16T19:50:01.2122972Z panic: test timed out after 10m0s
2023-05-16T19:50:01.2123256Z running tests:

[MarcoPolo]

Windows seems to perform pretty badly on QUIC and WebTransport (and also mplex?):

• https://github.com/libp2p/go-libp2p/actions/runs/4995852755/jobs/8948254733?pr=2296#step:8:2893

Ubuntu for reference:

• https://github.com/libp2p/go-libp2p/actions/runs/4995852755/jobs/8948254593?pr=2296#step:8:4306

[BigLep]

@MarcoPolo : I saw you closed this. Is that because there is a replacement PR coming?

[MarcoPolo]

@MarcoPolo : I saw you closed this. Is that because there is a replacement PR coming?

Fat fingered thanks for the flag.

[MarcoPolo]

I'd lean towards skipping windows tests for now and creating a tracking issue so as not to block WebRTC integration. Thoughts @marten-seemann ?

I'm also spinning up a Windows VM to try to investigate this a bit as well.

[MarcoPolo]

Hmm windows qlog does not look good. Large latency in the RTT measurement and the session takes ~300ms with a lot of gaps of inactivity on a recording with just 2 streams.

Here's the qlogs:
qlogs.zip

@marten-seemann could you take a look if anything obvious jumps out to you?