Store sampling context in the AsyncContextFrame directly

[szegedi]

What does this PR do?:

• Discards the CPED approach where we replace the AsyncContextFrame (ACF) object in the CPED with a proxy that has an internal field for our sample context.
• Instead, adopts an approach where the sample context is stored directly in the ACF map under an arbitrary key.
• It is possible to pass in a key externally. Passing in an AsyncLocalStorage as the key will allow the sampling context object to be retrieved from JavaScript using storage.getStore() on that object. This opens the possibility of implementing custom contexts in dd-trace-js.
• Also adds a createContextHolder method for direct use of custom contexts with AsyncLocalStorage.run()

Motivation:
Simplification, performance, and additional capabilities.
Simplification: Storing the sampling context directly in the ACF reduces the runtime complexity by not having a proxy object. Arguably, there's the added complexity of having the raw memory map reading code, but there's only so much complexity you can reduce and the remaining inherent complexity you can just push around.
Performance: We also no longer need to ensure that the proxy object is updated every time a new async context is created, thus dd-trace-js no longer needs to instrument AsyncLocalStorage.enterWith, eliminating the need to do any JS work in any callback on context creation or switches. I think this is pretty significant.
Additional capabilities: with the addition of createContextHolder it will be possible to implement an API like profiler.runWithCustomLabels(labels, fn) in dd-trace-js.

Additional Notes:
While storing the sampling context is now simpler, retrieving it from the signal handler actually got more complex, but that's a tradeoff we should make. Namely, in the signal handler now we need to chase pointers from current isolate to the hash table backing the ACF storage, and then also implement the hash table lookup-by-key. None of these data structures are published by V8, but we're defining equivalent ones that hold for the currently used V8 versions. They would also need to be updated if V8 internally changes them, but we have enough tests to detect if they no longer work.

For review, let me note that the first 4 commits are reverts of all the commits for the previous approach, so they just establish a clean slate on which to build the new approach. Few of the commits are just tests, or fixes for small things, or adjustments to make the big ones easier.
The big changes are all in these three commits:

• Read V8 map data directly, for signal safety,
• Allow passing in an ACF key object externally to the profiler., and
• Add timeProfiler.runWithContext

If needed, I could probably pull this apart into several smaller PRs, LMK.

How to test the change?
All existing CPED tests pass, and I've added some additional tests in test-get-value-from-map-profiler.ts. Funnily enough, for these tests I was creating profiler instances, but not starting them, which exposed (through ASAN, bless its name) some asymmetry in construction and destruction of WallProfiler that's not normally problematic (as normally time-profiler.ts always starts a created instance) but I fixed them anyway (specifically, registration of GC callbacks got moved from constructor to StartImpl and detachment and destruction of live context pointers got moved from Dispose to the actual ~WallProfiler.

[github-actions]

Overall package size

Self size: 1.81 MB
Deduped: 2.19 MB
No deduping: 2.19 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | source-map | 0.7.6 | 185.63 kB | 185.63 kB | | pprof-format | 2.2.1 | 163.06 kB | 163.06 kB | | p-limit | 3.1.0 | 7.75 kB | 13.78 kB | | delay | 5.0.0 | 11.17 kB | 11.17 kB | | node-gyp-build | 3.9.0 | 8.81 kB | 8.81 kB |

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-01-27 16:57:47

Comparing candidate commit 30c38cb in PR branch szegedi/acf-simple with baseline commit 947f5cf in branch main.

Found 0 performance improvements and 1 performance regressions! Performance is the same for 90 metrics, 29 unstable metrics.

scenario:profiler-light-load-no-wall-profiler-22

• 🟥 cpu_user_time [+1.599ms; +7.812ms] or [+2.237%; +10.924%]