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 7 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.