NODEJS-692: Add Node.js v24 to CI

[SiyaoIsHiding]

No description provided.

[absurdfarce]

Jenkins build running now; assuming everything is green there with these changes I think we're ready to go.

[absurdfarce]

So we're seeing two discrete problems here for our internal builds when using node 24.x. I'm documenting this here mainly because (a) it seems like the right place and (b) I don't want to forget the details here. I don't have a good answer to this problem yet beyond moving to npmjs.org for handling packages... this still needs more thought.

We use an internal npm cache for our builds. And just as we do with our other drivers we aim to build and test against all platform versions (specifically LTS versions in the case of node.js) which aren't EOL at time of release. As this PR makes clear the goal here is to test against 20.x, 22.x and 24.x.

Problem the first: our internal npm cache doesn't seem to be able to handle multiple versions of the same dependency. I can ask for yocto-queue 0.1.0 or 1.2.1 and the cache will load and store them exactly as expected. If I then ask for the other version without first clearing the cache I get errors indicating that the URL can't be found. I should also note that we see this behaviour if yocto-queue 1.2.1 is pre-loaded and I try to build with node.js 20.x (which should generate valid URLs to grab version 0.1.0)... so this issue doesn't appear to be connected to the second issue (discussed below).

Problem the second (and likely much more important)... node.js 24.x is generating very different URLs when requesting dependencies. Let's assume we have something like registry = https://somehost/somepath/npmjs-registry/ in ~/.npmrc. npm for 20.x and 22.x will generate a URL like http://somehost/somepath/npmjs-registry/yargs-unparser/-/yargs-unparser-2.0.0.tgz. This format is consistent with the format of our npm cache and the URL space it exposes. Cool, so far so good... all our 20.x and 22.x builds are green as a result.

With node.js 24.x and the exact same configuration we're now seeing a request for the exact same dependency made to https://somehost/yargs-unparser/-/yargs-unparser-2.0.0.tgz. The result is a 404 response code for every dependency in package.json.

There may be some interaction between these issues but based on what I've seen so far they exist as discrete problems.