process: preserve AsyncLocalStorage on queueMicrotask only when needed

[gurgunday]

Does the same optimization as #59873 for queueMicrotask

branch:

./node benchmark/run.js --filter queue-microtask process

process/queue-microtask-breadth.js
process/queue-microtask-breadth.js n=400000: 18,938,347.488090977

process/queue-microtask-depth.js
process/queue-microtask-depth.js n=1200000: 35,862,646.06556887

main

./node benchmark/run.js --filter queue-microtask process

process/queue-microtask-breadth.js
process/queue-microtask-breadth.js n=400000: 5,198,220.087856157

process/queue-microtask-depth.js
process/queue-microtask-depth.js n=1200000: 12,707,696.847598467

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.58%. Comparing base (6274eb7) to head (2f8776e).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #60913      +/-   ##
==========================================
+ Coverage   88.55%   88.58%   +0.02%     
==========================================
  Files         703      703              
  Lines      208291   208296       +5     
  Branches    40170    40166       -4     
==========================================
+ Hits       184443   184509      +66     
+ Misses      15874    15807      -67     
- Partials     7974     7980       +6     

Files with missing lines	Coverage Δ
lib/internal/process/task_queues.js	100.00% <100.00%> (ø)

... and 48 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gurgunday]

cc @nodejs/performance

WDYT?

[H4ad]

Before merging, some concerns raised in another PR with same changes:

One thing worth noting is that this would be a breaking change as currently the AsyncLocalStorage.bind(...) will always bind, even if there are no hooks or stores in use, but async_hooks could start listening at any time. In the current model you could start listening after the bind call there but before the callback is called and you would see the events. After this change you would not.
By @Qard

Would mind giving some thoughts on this one, @mcollina and @Qard?

Edit:
Benchmark: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1770/

[github-actions]

Failed to start CI

   ⚠  No approving reviews found
   ✘  Refusing to run CI on potentially unsafe PR

https://github.com/nodejs/node/actions/runs/19980375054

[Qard]

@H4ad Yes, the same concern applies. It is, in my opinion, problematic that it was ever possible to start seeing events for a given task partway through its lifecycle rather than deciding at emit time if any of the events should be present. But that is certainly a breaking change and so should be marked as such. A desirable change, I think. But a breaking one nonetheless.

At the same time though, async_hooks is still marked as experimental, and AsyncLocalStorage no longer relies on it, so the break is likely a lot less critical. We may be able to allow it without a major bump. I'm not strongly opinionated either way.

[mcollina]

lgtm

[mcollina]

I'm ok in this being a minor, but I don't think we can backport it to 22.