feat: add diagnostic channels for request lifecycle

[OussemaNehdi]

Summary

Adds diagnostics_channel support for Express request lifecycle, as requested
in #6353. This enables APM and monitoring tools to observe request processing
without monkey-patching.

Channels

Channel	When	Message
express.request.start	Before routing begins	{ req, res }
express.request.finish	Response fully sent	{ req, res }
express.request.error	Connection error (ECONNRESET, etc.)	{ req, res, error }

Design decisions

• Zero overhead: Every publish() call is guarded by hasSubscribers,
  so there is no performance cost when no diagnostic tool is listening
• on-finished for completion tracking: Uses the existing on-finished
  dependency (already used by res.sendFile) to detect when the response is
  fully sent, covering all code paths including streaming and error responses
• Complements feat: add diagnostics_channel support for app initialization #7041: PR feat: add diagnostics_channel support for app initialization #7041 adds an express.initialization channel for
  app startup. This PR covers the request lifecycle, which is the primary use
  case for APM tools like OpenTelemetry and Datadog

Example usage

const dc = require('node:diagnostics_channel');

dc.subscribe('express.request.start', ({ req, res }) => {
  req._startTime = performance.now();
});

dc.subscribe('express.request.finish', ({ req, res }) => {
  const duration = performance.now() - req._startTime;
  console.log(`${req.method} ${req.url} ${res.statusCode} ${duration.toFixed(1)}ms`);
});

Test plan

- express.request.start publishes before routing with { req, res }
- express.request.start fires for every request (verified with 2 sequential requests)
- No overhead when no subscribers (request works normally)
- express.request.finish fires after response with correct statusCode
- express.request.finish fires for 500 error responses
- express.request.finish fires for 404 responses
- express.request.error does NOT fire on normal responses
- start always fires before finish (ordering verified)
- All 1257 tests pass (1252 existing + 5 new)
- ESLint clean 

[logaretm]

I think we should consider using tracing channels instead, for one they exist in Node 18 and they offer context propagation across the events emitted so APMs and subscribers don't have to do it manually.

Also I think we should move it to pillarjs/router to target the grantuality needed here. There is a previous attempt in pillarjs/router#96

[Qodo-Free-For-OSS]

Hi, app.handle publishes express.request.finish even when on-finished reports an error, so aborted/failed connections can be reported as “response fully sent”. This breaks the channel’s documented meaning and will skew APM/metrics by counting aborted requests as finished successfully.

Severity: action required | Category: correctness

How to fix: Gate finish publish on !err

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

express.request.finish is currently published even when on-finished reports an error (e.g., premature close / ECONNRESET). This contradicts the documented meaning (“response fully sent”) and causes aborted requests to be counted as finished.

Issue Context

on-finished invokes its callback with err on abnormal termination. Express already treats on-finished errors as aborted/error in lib/response.js.

Fix Focus Areas

• lib/application.js[185-194]
  • Only publish requestFinish when err is falsy.
  • Keep publishing requestError when err is truthy.
  • Consider whether requestFinish should still publish for some specific error types (if so, encode that explicitly rather than unconditional publish).

We noticed a couple of other issues in this PR as well - happy to share if helpful.

---

Spotted by Qodo code review - free for open-source projects.