feat(streams): limit usage in body mixin #2164

[rozzilla]

This relates to...

Fixes #2164

Rationale

When a Response or Request body is created from a string or Uint8Array, the body mixin methods (text(), json(), arrayBuffer(), blob(), bytes()) currently pipe the source through a ReadableStream even though the bytes are already available in body.source. This adds unnecessary overhead from stream construction, pump microtasks, and chunk collection.

Changes

1. In consumeBody(), before calling fullyReadBody(), check if body.source is a string or Uint8Array. If so, bypass the stream round-trip and pass the source bytes directly to successSteps
2. Add tests covering string sources (all 5 body mixin methods, Request, multibyte, empty), Uint8Array sources (text, arrayBuffer, bytes, blob), body unusability after consumption (bodyUsed, double-read rejection), and non-shortcuttable sources (ReadableStream, Blob, null) to ensure the normal path is unaffected.

Features

N/A

Bug Fixes

N/A

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Benchmarked (optional)
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.93%. Comparing base (0143e1b) to head (792b7be).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5010      +/-   ##
==========================================
- Coverage   92.93%   92.93%   -0.01%     
==========================================
  Files         110      110              
  Lines       35739    35755      +16     
==========================================
+ Hits        33214    33228      +14     
- Misses       2525     2527       +2     

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KhafraDev]

The issue with optimizations like these (if it's even more performant, I'm not sure that it is) is that it encourages people to only use string or Uint8Array bodies to squeeze more performance out of node. I don't want to recreate CrankshaftScript.

[mcollina]

How much is more performant? I think that in most cases, those optimizations are good for Node.js.

[KhafraDev]

It wouldn't matter. The implementation is incorrect as it doesn't perform the same validation readAllBytes does (ensuring the result of reader.read() is a Uint8Array). After that I'm not sure, 1 less promise, for the extra maintenance burden and guaranteed bugs there will be?