jest runtime slower then non-bazel

[jbedard]

Mostly due to fs sandboxing. The readlinkSync call in nextHopSync fails and throws on most invocations causing substantial cpu usage calculating stack traces.

1. Minimize work when calculating stack traces (reduced test time by 50%): perf: prevent preparing stack traces in fs *Sync patches rules_js#546
2. reduce directory traversing: perf: cache fs patch fs lookups  rules_js#569
3. avoid work when outside the sandbox, cache more: perf: fs performance improvements rules_js#1007

[gregmagolan]

Measure 3 things:

• non-bazel
• rules_js with patches and no sandbox
• rules_nodejs with patches and no sandbox

[gregmagolan]

also measure: Is the patches overhead a one-time start-up cost or does is scale with number of test cases/specs

[jbedard]

Overall the times with vs without the patches scale along with the number of tests, which I assume means number of files loaded. With a single test it seems about 8% slower, with 2k tests it was about 5% slower (using the best times with ~5 tries, very inaccurate but consistent enough I'll trust them).

[rc-glean]

Curious whether aspect's "mac as local dev" customers|partners|users prefer to disable sandboxing on mac per bazelbuild/bazel#8230 (comment). Confirming that we also tried --experimental_reuse_sandbox_directories and it doesn't seem to help.

Some anecdata: one of our jest test suites (Glean closed source) running under aspect takes ~6x longer to execute with the sandbox enabled vs not. 1 minute vs 6 minutes.