fs: add diagnostics_channel tracing - #66575

This adds a diagnostics_channel TracingChannel for each node:fs operation. It is a different approach to #65370, based on the review feedback there.

Each operation publishes to tracing:fs.<operation>:*, for example tracing:fs.stat:start. The sync, callback and promise forms of an operation share a channel, so a subscriber to fs.readFile sees fs.readFile(), fs.readFileSync(), fsPromises.readFile() and filehandle.readFile(). The context has api ('sync', 'callback' or 'promise'), args (a copy of the arguments as passed), and the leading arguments by name, such as path, fd and dest. The docs have the full list.

The events are published from JS with traceSync(), traceCallback() and tracePromise(), so all events of one call share one context object, error is always followed by end or asyncEnd, asyncStart has result, and bindStore() works. Buffers and the other arguments are passed by reference in args. The readFile and writeFile one-round-trip paths, fsPromises.readFile(), readFileSync() with an encoding, existsSync() and the FileHandle methods all publish.

Each traced function starts with one line, for example if (shouldTraceFs('stat')) return traceFsCallback('stat', stat, this, arguments);. When the channel has subscribers, the helper calls the same function again inside the trace, and a flag makes that inner call skip the check. The whole body then runs inside the start scope. This matters for bindStore(): the FSReqCallback or binding promise must be created inside the scope, because a request created before it does not carry the store to the callback. Nested fs calls also run inside the parent's store. Because the check is in the function body, captured references and ESM named imports still publish. When nothing subscribes, the rest of the body is the same as on main.

Calls with invalid arguments publish start, error and end. Calls that a VFS handler serves also publish. fsPromises.glob(), fs.watch(), fs.watchFile() and dir.read() do not publish. An operation that uses other fs operations publishes those too, inside its own events. For example, fs.readFileSync() without an encoding publishes fs.open, fs.read and fs.close inside fs.readFile.

With plain compare.js, the async and stream benchmarks in benchmark/fs do not change, but some short sync benchmarks are slower. With 15 runs and no subscribers, fstatSync was about 5% slower, statSync about 3%, and failing readFileSync calls 5% to 9%. Most of this is the cost of TracingChannel.hasSubscribers before V8 optimizes it. Many of these benchmarks do 10,000 calls in a new process, so most checks run while the getter is still in the interpreter or in Sparkplug. There, the getter calls BoundedChannel.hasSubscribers and Channel.hasSubscribers for all five channels, which costs 60 to 100 ns per check. Once it is optimised, it costs about 3 ns. Next to a 300 to 900 ns sync call, the difference shows.

Once hasSubscribers has been optimized, calling it becomes insignificant apart from sync calls that throw. These are 1-3% slower. When an exception passes through a function that runs as Sparkplug code, V8 finds the bytecode offset with a linear walk from the start of the function (Code::GetBytecodeOffsetForBaselinePC, from Isolate::Throw and LookupExceptionHandlerInTable). So any code before the binding call makes each throw slower. A single if (x.active !== 0) return; costs about 50 ns per failing openSync() there. I did not find a way around this.

I did not change the benchmarks to warm the hasSubscribers getters. A follow-up could make TracingChannel.hasSubscribers cheaper before optimisation.

The new tests cover the event order, the shared context, bindStore() across callbacks, promises and nested calls, and the FileHandle methods. A coverage test fails if a public fs function does not publish, or publishes more than once.

Fixes: #65330
Refs: #65370
CC: @nodejs/diagnostics

This PR was partly AI generated but everything was reviewed by a water based human