quic: fix infinite loop if STOP_SENDING received on a buffering stream

[pimterry]

The HTTP/3 application implements StreamWriteShut to clean up streams after ngtcp2 reports NGTCP2_ERR_STREAM_SHUT_WR (generally when STOP_SENDING is received).

The default application does not. This meant it fell into a busy loop in ngtcp2 where it tried to send the data constantly in a loop forever, blocking the process. Test here reproduces this: the server accepts the stream but never reads, the client writes enough data to end up buffered, the server sends STOP_SENDING => 100% CPU never exits.

The default QUIC app now unschedules the stream when it's shut, which fixes the test.

This is largely independent of #64710. It fails with or without that change. In effect that PR changes the callback & frame-level behaviour around STOP_SENDING, while this one fixes a bug in the low-level writing behaviour for closed stream errors.

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (6572cf5) to head (c7ecaf2).
⚠️ Report is 239 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64715 +/- ##
==========================================
- Coverage 90.13% 90.12% -0.02% 
==========================================
Files 741 741 Lines 242251 242251 Branches 45615 45624 +9 ==========================================
- Hits 218355 218319 -36 - Misses 15396 15431 +35 - Partials 8500 8501 +1 

see 29 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75652/

[nodejs-github-bot]

Landed in a876a12