http: fix http client leaky with double response

[theanarkh]

Fixed: #60025

When a request corresponds to multiple responses, ensure that only the first one is processed and skip all subsequent invalid responses (or emit a response event then emit an error event on request object ?).

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

Review requested:

• @nodejs/http
• @nodejs/net

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.46%. Comparing base (c6316f9) to head (169eabb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #60062   +/-   ##
=======================================
  Coverage   88.45%   88.46%           
=======================================
  Files         703      703           
  Lines      207546   207553    +7     
  Branches    40011    40008    -3     
=======================================
+ Hits       183591   183606   +15     
+ Misses      15949    15941    -8     
  Partials     8006     8006           

Files with missing lines	Coverage Δ
lib/_http_client.js	97.35% <100.00%> (+0.01%)	⬆️
lib/_http_common.js	100.00% <100.00%> (ø)

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

[pimterry]

One minor point, otherwise LGTM.

---

or emit a response event then emit an error event on request object ?

Emitting an error here would be a breaking change that will probably break things for some people in real cases. Without that, I don't think this is semver-major, since other than the leak the 2nd response doesn't seem to have been observable until now.

I think emitting an error would probably still be best, because it is an error case where something's clearly gone wrong, and this matches our docs, which say

If any error is encountered during the request (be that with DNS resolution, TCP level errors, or actual HTTP parse errors) an 'error' event is emitted on the returned request object

but that said, it might be better to separate the two issues.

How about we aim to ship this to resolve the leak, and then ship a separate semver-major PR making this into an emitted request error in future?

[pimterry]

I think this should probably be a kSkipPendingData symbol, just to make sure this doesn't accidentally become a public API at some point.