fix: Create a single TaskBlockingListener per process for CaptureBlockingCalls

[jamescrosswell]

Summary

Fixes a per-request resource leak in CaptureBlockingCalls (ASP.NET Core), reported in #5378.

SentryMiddleware implements IMiddleware and is registered with AddTransient<SentryMiddleware>(), so DI constructs a new instance per request. With CaptureBlockingCalls = true, its constructor created a new TaskBlockingListener (a System.Diagnostics.Tracing.EventListener) on every request and never disposed it:

_monitor = new BlockingMonitor(_getHub, _options);
_detectBlockingSyncCtx = new DetectBlockingSynchronizationContext(_monitor);
_listener = new TaskBlockingListener(_monitor); // registers itself globally, never disposed

Every EventListener registers itself in the runtime's process-global listener chain and enables TplEventSource (Verbose). So the chain grew by one per request and EventSource.DispatchToAllListeners walked the whole (ever-growing) chain on every task-wait event of every await in the process — not just inside requests.

The reporter observed, on effectively-idle services (only a 10s healthcheck): p95 of a trivial endpoint growing ~5 ms → ~150 ms over 5 days (~45k requests → ~45k leaked listeners), 96–97% of CPU inside EventSource.DispatchToAllListeners, and steadily growing background CPU and managed heap — all reset by a restart. Full credit to @gerardfontmora for the diagnosis.

Fix

• Register BlockingMonitor and TaskBlockingListener as singletons, and have the transient middleware resolve (rather than construct) them, so exactly one TaskBlockingListener exists per process with constant overhead. They are only resolved when CaptureBlockingCalls is enabled, so disabling the feature has no cost.
• The per-request DetectBlockingSynchronizationContext swap in InvokeAsync is unchanged — it carries per-request suppression state and is correctly created per request.
• Drive-by: TaskBlockingListener.DefaultState was an expression-bodied property (=> new()) that allocated a fresh Lazy<> on every access instead of returning a single shared instance; changed to a static auto-property.

Regression test

Constructor_CaptureBlockingCalls_SharesSingleListenerAcrossInstances builds two middleware instances (simulating two requests) and asserts they share one Listener/Monitor. Verified it fails against the previous per-request construction and passes with this change.

Fixes #5378

[codecov]

Codecov Report

❌ Patch coverage is 71.42857% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.28%. Comparing base (5e9a7c4) to head (6724a01).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
src/Sentry.AspNetCore/SentryMiddleware.cs	60.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5381      +/-   ##
==========================================
+ Coverage   74.25%   74.28%   +0.03%     
==========================================
  Files         509      509              
  Lines       18420    18427       +7     
  Branches     3606     3606              
==========================================
+ Hits        13677    13688      +11     
+ Misses       3869     3866       -3     
+ Partials      874      873       -1     

☔ View full report in Codecov by Harness.
📢 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.

[bruno-garcia]

LGTM, I'd add some integration tests too as a follow up

[jamescrosswell]

LGTM, I'd add some integration tests too as a follow up

Follow up issue:

• Add integration tests for CaptureBlockingCalls blocking detection #5394