feat(NODE-7306): Replace global process with import node:process

[PavelSafronov]

Description

Summary of Changes

The driver will explicitly import node:process instead of relying on the global.
eslint rule no-restricted-globals is also enabled.

What is the motivation for this change?

This helps us reduce our runtime dependencies, as part of https://jira.mongodb.org/browse/NODE-6601

Release Highlight

Replaced global process with node-specific process

This forces an explicit require and doesn't use global.process, allowing bundlers to supplant the variable consistently.

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

[addaleax]

Are you sure you want this? How does it reduce runtime dependencies?

globals are generally much easier to polyfill (/existing polyfills already handle them), so this seems counterintuitive.

The vast majority of these are accesses to process.nextTick() or process.env; I still think you'll want queueMicrotask() as a replacement for the former, and the environment I'd consider passing to the MongoClient as an option (with process.env as the default value)

[PavelSafronov]

Are you sure you want this?

This is one of the intentions of this doc, to remove the dependence on a global process: Design: Remove dependence on runtime specific APIs.

How does it reduce runtime dependencies?

This change itself doesn't, but it allows bundlers to supplant the variable consistently.

The vast majority of these are accesses to process.nextTick() or process.env; I still think you'll want queueMicrotask() as a replacement for the former, and the environment I'd consider passing to the MongoClient as an option (with process.env as the default value)

The queueMicrotask change will go in first, then I'll update this PR and mark it ready. We will eventually allow a way for users to pass this information to the client, but that is part of the later milestones.

[nbbeeken]

This is one of the intentions of this doc, to remove the dependence on a global process

That line is perhaps ill informed, I wrote that with some experience bundling the driver being more difficult when needing to replace a global vs an imported module, since importing had a clearer entry point for the stub. This was in the very early stages of the driver bundling project when it was more of a hackathon project. I defer to @addaleax on what is actually easier to achieve now that the driver stubbing is more isolated. If I recall a sticking point was that the process polyfill that already existed in cloud was somehow slightly incorrect for what the driver depended upon but a better replacement would have broken the existing usage, so it wasn't that polyfilling a global was hard it was about getting the right one into the driver.

I do think that the "node:" namespaced imports are at least at this time difficult for bundling to handle / supplant, but not certain of that.