…puriously fire

The JS-based `ConnectionsList` introduced by #33208 defines
`markHeadersCompleted()` and `popActive()` but they were never called,
so every server connection sat in `_active` with `headersCompleted: false`
and a fixed `startTime`. The 30s `checkConnections` watchdog then fired
a spurious `ERR_HTTP_REQUEST_TIMEOUT` ~60s into any long-lived request,
which Fastify (and similar frameworks) convert into HTTP 400 via the
`clientError` event handler.

Mirror Node's native `on_message_begin` / `on_headers_complete` /
`on_message_complete` behavior in JS:

- `parser[kOnMessageBegin]` → popActive + pushActive (resets the
  per-request timer; also covers keepalive: the 2nd request on a
  socket gets a fresh window).
- `parserOnIncoming` → markHeadersCompleted (silences `headersTimeout`
  once headers are parsed; `requestTimeout` continues to count).
- `resOnFinish` → popActive (stop tracking once the request is done).

Fixes #34297

The initial fix called `popActive(socket)` from `resOnFinish`, but for
pipelined requests the parser has already fired `kOnMessageBegin` for
the next request before the previous response finishes — so popping the
entry wrongly removed the tracking state of the in-flight next request,
and `headersTimeout`/`requestTimeout` would never fire for it.

Replace `popActive` with `popActiveIfCompleted`, which only clears the
entry when its `headersCompleted` flag is still true (the just-completed
request); the parser's `kOnMessageBegin` callback resets the flag back
to false when a new message starts, so a pipelined entry survives the
prior request's resOnFinish.

Also stop refreshing the socket timeout from `onParserExecute` while
the connection is in keep-alive idle mode (`state.keepAliveTimeoutSet`
is true). A stray `\r\n` from a client between requests must not extend
keepAliveTimeout — the timer is reset explicitly by `resetSocketTimeout`
when a new request actually begins.

Adds a Deno unit test reproducing the original bug (long-running
handler with a small `headersTimeout` must not get a spurious
`ERR_HTTP_REQUEST_TIMEOUT`), and ignores
`test-http-keep-alive-empty-line` — that test was previously passing
only because the buggy ConnectionsList was closing sockets early; making
it pass for the right reason requires a separate fix to keepAliveTimeout
firing on consumed sockets.

popActiveIfCompleted only inspected headersCompleted, so finishing the
first response in a pipeline deleted the active entry that already
belonged to the next request (parser fires kOnMessageBegin while res1
is still in flight, replacing the entry). After that, headersTimeout /
requestTimeout silently stopped covering the pipelined successor.

markHeadersCompleted now stores the req on the entry, and resOnFinish
calls popActiveIfReq(socket, req) which only deletes when the entry
still tracks the request whose response just finished.

Adds a pipelined regression test that sends two HTTP/1.1 requests on
one socket and verifies both responses succeed without a spurious
clientError.

…list-timeout

# Conflicts:
#	ext/node/polyfills/_http_server.js