Assert we drained the microtask queue since the last time we called into JavaScript

[Jarred-Sumner]

What does this PR do?

This adds an assertion in debug builds that checks we called drainMicrotasks after calling into a JavaScript function.

This adds a helper method EventLoop.runCallback for calling into JavaScript functions from the top of the event loop. This will handle exceptions and release weakrefs and anything else we may need to do in the future.

This also fixes cases where we weren't draining microtasks in:

• IPC
• open() callback in Bun.listen/Bun.connect
• open and close callbacks in Bun.serve() WebSockets
• H2

The panic looks like this:

uh-oh: 1 JavaScript functions were called outside of the microtask queue without draining microtasks.

Last function name: open

Use EventLoop.runCallback() to run JavaScript functions outside of the microtask queue.

Failing to do this can lead to a large number of microtasks being queued and not being drained, which can lead to a large amount of memory being used and application slowdown.
bun will crash now 😭😭😭

It only tracks function names if BUN_TRACK_LAST_FN_NAME=1

How did you verify your code works?

Manually

[github-actions]

❌ @Jarred-Sumner 3 files with test failures on bun-darwin-aarch64:

• test/cli/install/registry/bun-install-registry.test.ts 1 failing
• test/cli/test/bun-test.test.ts 1 failing
• test/js/third_party/webpack/webpack.test.ts 1 failing

View test output

^{#df98a8cdc3c47bd6bb1491f7bc399448571e724a}

[github-actions]

❌ @Jarred-Sumner 3 files with test failures on linux-x64-baseline:

• test/cli/test/bun-test.test.ts 1 failing
• test/integration/next/default-pages-dir/test/next-build.test.ts 1 failing
• test/js/third_party/webpack/webpack.test.ts 1 failing

View test output

^{#df98a8cdc3c47bd6bb1491f7bc399448571e724a}

[github-actions]

❌ @Jarred-Sumner 3 files with test failures on linux-x64:

• test/cli/test/bun-test.test.ts 1 failing
• test/integration/next/default-pages-dir/test/next-build.test.ts 1 failing
• test/js/third_party/webpack/webpack.test.ts 1 failing

View test output

^{#df98a8cdc3c47bd6bb1491f7bc399448571e724a}

[github-actions]

❌ @Jarred-Sumner 6 files with test failures on bun-darwin-x64:

• test/cli/test/bun-test.test.ts 2 failing
• test/js/bun/util/which.test.ts 1 failing
• test/js/node/fs/fs.test.ts 1 failing
• test/js/third_party/postgres/postgres.test.ts 1 failing
• test/js/third_party/webpack/webpack.test.ts 1 failing
• test/js/web/workers/worker.test.ts 1 failing

View test output

^{#df98a8cdc3c47bd6bb1491f7bc399448571e724a}

[github-actions]

❌🪟 @Jarred-Sumner, there are 10 test regressions on Windows x86_64

• test\bundler\cli.test.ts
• test\bundler\esbuild\loader.test.ts
• test\cli\run\transpiler-cache.test.ts
• test\js\bun\console\console-iterator.test.ts
• test\js\bun\util\bun-file-windows.test.ts
• test\js\node\http\node-http.test.ts
• test\js\node\module\node-module-module.test.js
• test\js\third_party\postgres\postgres.test.ts
• test\regression\issue\08095.test.ts
• test\transpiler\template-literal.test.ts

Full Test Output

[dylan-conway]

should it be an assertion that it's never negative?