fix(fetch): drain redirect response bodies so pooled connections are released

[Kjubikstronk]

Closes #5728.

httpRedirectFetch follows a redirect without ever consuming the 3xx response body. That response is never exposed to the caller, so nothing else reads it either, and the connection it arrived on stays unusable. With a pooled dispatcher each redirect can hold a slot, so a connections: 1 agent deadlocks: the follow-up request queues behind a socket that is still holding an unread body.

request() does not have this problem. RedirectHandler.onResponseData swallows 3xx chunks but keeps reading them, which drains the socket. This makes fetch do the same.

Why not just cancel the stream

That was my first attempt and it is wrong in a way worth recording. The body stream's cancel algorithm is:

const cancelAlgorithm = (reason) => {
  if (!isCancelled(fetchParams)) {
    fetchParams.controller.abort(reason)
  }
}

It aborts fetchParams' controller, and httpRedirectFetch then calls mainFetch on that same controller, so cancelling the redirect body aborts the redirect you are about to follow. The repro still hung. Draining is the only option that frees the socket without touching the controller.

Test

test/fetch/redirect-body-drain.js, close to the reporter's script: a 301 carrying 128 KiB, an Agent with connections: 1, and a follow-up that has to reuse that socket. It passes in ~25ms with the change and hangs until the timeout without it, so it fails for the right reason.

Verification

• test/redirect-request.js, test/redirect-stream.js, test/redirect-pipeline.js: 109/109
• test/fetch/*.js: 457 passed / 13 failed, and the same 13 fail on an unmodified tree. They are the GC, finalizer and --max-http-header-size tests that need runner flags this invocation does not pass. I checked fire-and-forget.js specifically, since its name is close to this behaviour, and it fails identically with and without the change.
• eslint clean.

Draining does read the redirect body rather than discarding it unread, which matches what RedirectHandler already does for request(). If you would rather destroy the connection than read the body on large redirects, I am happy to change the approach.