Add global Stream tracker in debug builds

[anrossi]

Description

Help debug lost reference issues in MsQuic by keeping a global list of streams.

Testing

CI

Documentation

N/A

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.29%. Comparing base (d3d182c) to head (8465cc6).
⚠️ Report is 47 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5598      +/-   ##
==========================================
+ Coverage   84.81%   85.29%   +0.47%     
==========================================
  Files          60       60              
  Lines       18647    18658      +11     
==========================================
+ Hits        15816    15914      +98     
+ Misses       2831     2744      -87     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mtfriesen]

Nit: I'd suggest simplifying this to one lock for all the trackers.

[mtfriesen]

I've never seen this pattern before - is there a precedent for it in MsQuic? If not, let's use the init routine.

[mtfriesen]

I think we may want to introduce some abstractions for these trackers, such that if perf becomes a practical bottleneck on debug builds, we can:

1. Easily add some more fields beyond the list entry
2. Easily replace the single global list with something more sophisticated, such as a per-CPU list

[guhetier]

I am not convinced this helps given that AllStreamsLink already exists + the debugger extension. The PR is adding / removing to the list in the exact same spot as for AllStreamsLink. It seems redundant to me.

[mtfriesen]

I am not convinced this helps given that AllStreamsLink already exists + the debugger extension. The PR is adding / removing to the list in the exact same spot as for AllStreamsLink. It seems redundant to me.

The debugger extension is fine, but isn't cross platform. We need a way to provide simple debugging steps for all platforms, so having simple, manually-inspectable lists seems the path of least cost and most reliability.

In terms of the stream tracker specifically being redundant, I agree it's perhaps a lower value object if the owning connections can be reliably found. I'd think of this PR more as a litmus test for the general model than a standalone PR that will dramatically change the debugging experience by itself.

[guhetier]

I am not convinced this helps given that AllStreamsLink already exists + the debugger extension. The PR is adding / removing to the list in the exact same spot as for AllStreamsLink. It seems redundant to me.

The debugger extension is fine, but isn't cross platform. We need a way to provide simple debugging steps for all platforms, so having simple, manually-inspectable lists seems the path of least cost and most reliability.

In terms of the stream tracker specifically being redundant, I agree it's perhaps a lower value object if the owning connections can be reliably found. I'd think of this PR more as a litmus test for the general model than a standalone PR that will dramatically change the debugging experience by itself.

Good point for the debugger extension. It still feels redundant to me, or at least, I have a hard time thinking of a scenario where this global list brings much value over the per-connection list.

If there are scenarios, it would be good to extend our trouble shooting guide (or have another doc file focused on debugger) with a list of those debug helpers and when they are relevant. It will be easier to do as we go.

[mtfriesen]

Good point for the debugger extension. It still feels redundant to me, or at least, I have a hard time thinking of a scenario where this global list brings much value over the per-connection list.

If there are scenarios, it would be good to extend our trouble shooting guide (or have another doc file focused on debugger) with a list of those debug helpers and when they are relevant. It will be easier to do as we go.

I stumbled onto a concrete example of why we need the simple, robust object tracker:

msquic/src/core/connection.c

Lines 335 to 344 in 9117f56

	#if DEBUG
	while (!CxPlatListIsEmpty(&Connection->Streams.AllStreams)) {
	QUIC_STREAM *Stream =
	CXPLAT_CONTAINING_RECORD(
	CxPlatListRemoveHead(&Connection->Streams.AllStreams),
	QUIC_STREAM,
	AllStreamsLink);
	CXPLAT_DBG_ASSERTMSG(Stream != NULL, "Stream was leaked!");
	}
	#endif

We can see that following the chain of references here by transitivity will fail, more or less by the existing design, and practically necessarily so, if expected object lifetime relationships break down. Since the lifetimes breaking down is exactly one interesting use case, splitting this into separate lists seems best.