feat(NODE-7335): Create dedicated mocha runner with isolated vm context

[PavelSafronov]

Description

Summary of Changes

Adds a way to run unit and integration tests against a special version of Node Driver where we block specific require calls. This is so we can be confident that our updates don't accidentally re-introduce a dependence on Node.

This PR also adds a number of Evergreen tasks for testing various combinations of the server with the "Node-less" VM. In these tasks we run all integ tests and most unit tests against the bundled and contextified version of the driver.

Notes for Reviewers

Take a look at the README updates, that should explain a lot about how this bundled testing works.

Below are steps for testing this out locally with timeout unit tests and CRUD API integ tests.

Steps to test unit tests

1. add the following lines to src/timeout.ts around line 62, in the private constructor

    // eslint-disable-next-line no-console, @typescript-eslint/no-require-imports
    console.log(`os platform is ${require('os').platform()}`);

2. npm run check:unit
3. note that all unit tests pass, though now they are logging stuff to the console
4. npm run check:unit-bundled
5. note that timeout tests failed with something like:

 Error: Access to core module 'os' (from new _Timeout (/Users/pavel.safronov/code/node-mongodb-native/srctimeout.ts:64:35)) is restricted in this context

Steps to test unit tests

1. add the following lines to src/mongo_client.ts, around line 430, in the constructor

    // eslint-disable-next-line no-console, @typescript-eslint/no-require-imports
    console.log(`os platform is ${require('os').platform()}`);

2. run "CRUD API" integ tests with npm run check:test
3. note that all unit tests pass, though now they are logging stuff to the console
4. run "CRUD API" integ tests with npm run check:test-bundled
5. note that integ tests fail with something like:

  1) CRUD API
       "before each" hook for "should correctly execute findOne method using crud api":
     Error: Access to core module 'os' (from new MongoClient (/Users/pavel.safronov/code/node-mongodb-native/src/mongo_client.ts:431:35)) is restricted in this context
      at restrictedRequire (test/tools/runner/vm_context_helper.ts:19:13)
      at new MongoClient (src/mongo_client.ts:431:35)
      at TestConfiguration.newClient (test/tools/runner/config.ts:333:12)
      at Context.<anonymous> (test/integration/crud/crud_api.test.ts:28:33)
      at processImmediate (node:internal/timers:505:21)

What is the motivation for this change?

To fail our tests if our code starts to use a prohibited import, so we can guarantee that the driver will work in a non-Node runtime.

Release Highlight

Release notes highlight

Double check the following

• Lint is passing (npm run check:lint)
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[nbbeeken]

There's the one comment about global the legacy Node.js-only property, if there's something still relying on it we can revisit that in a follow up, if not we can just drop it.

[addaleax]

Suggested change

	'Map',
	'Math',
	'Promise',

I'd still really look into why these are required before merging (if they indeed are), they're all JS builtins that should work just fine, and if they do not, it's going to be worth checking why that is

[PavelSafronov]

These are related to NODE-7460: our tests/chai uses instanceof calls. We'll be able to remove these additions after we upgrade to chai 5, which uses a different instance check that is amenable to different contexts.

[addaleax]

I think #4876 (comment) is still relevant here (this call isn't bundler-friendly by itself – we may be fine with that, but it's a change that at the very least requires config changes in downstream packages)

[tadjik1]

That's quite a list! Do we really need to test different mongodb versions here? The assumption is that different topologies might have different path branches we want to catch, but I think having either rapid or latest stable might be enough for the matrix, wdyt?

[PavelSafronov]

This was a first-pass addition of the node-less variant, so I may have been overenthusiastic with the list. Let me take a look at .evergreen/generate_evergreen_tasks.js and see if we can specify which tasks should run.

[PavelSafronov]

Current approach tosses everything in, which can cause issues: more tests means more chance for flaky failures, more resources spent, etc. I'm going to pare this list down to a hardcoded set of tasks that we will run in rhel8 and Windows. Updating now.

[tadjik1]

Fantastic work on documenting this new testing approach! 👍

[tadjik1]

Great work @PavelSafronov! 🥇