deps: update temporal_rs to 0.2.3

[Renegade334]

Submitting as an alternative to #63281, since we are going straight to rustc 1.88 in the build environment, which means we can upgrade this directly.

First, a note on the update methodology. The process I've used for the manifest and cargo lockfile is somewhat different to what we were doing before, and ensures that we are mirroring the exact locked dependencies in the Chromium snapshot, in a way that should be amenable to semi-automation. The steps used were:

1. Update deps/v8/DEPS with the target third_party/rust commit hash.
2. Obtain chromium_crates_io/{Cargo.toml,Cargo.lock} from https://chromium.googlesource.com/chromium/src/third_party/rust at the target commit.
3. In our own Cargo.toml:
   1. Update the crate version to match the new temporal_rs version.
   2. Update the crate's rust-version to that of temporal_rs.
   3. Copy across all of the icu_* and temporal_* dependency configs from Chromium's Cargo.toml, to ensure a feature-matched build. (Transitive dependencies which do not have config blocks in Chromium do not need listing here, but will be version-locked in the next step.)
4. Replace our own Cargo.lock with the one in the Chromium snapshot. (It contains a lot of entries that we don't need, but those will be pruned in the next step.)
5. Run cargo vendor.
   • temporal_rs and its dependencies will be vendored according to the matching entries in the Chromium lockfile, ensuring that every package in our dependency tree matches the one used by Chromium.
   • This step also prunes the lockfile, so all the dependencies there that don't exist in our own tree are removed.
6. Update workflows.

temporal_rs 0.2 contains a whole raft of bugfixes and spec compliance issues, which I think we are obliged to land before v26.x goes LTS, even though it doesn't match the dependency used in V8 14.6. There are no V8 changes required for this update to land, although there are one or two small Temporal compliance patches that we should probably cherry-pick independently.

Note that the ICU4X dependencies now contain vendored locale data, which is required for calendar operations in temporal_rs (boa-dev/temporal#693 (comment)). This increases the size of the vendored source by around 55KiB, but almost none of this is linked into the build, so the final binary size is unchanged. The inclusion of compiled locale data doesn't have any effect on Intl – temporal_rs doesn't do any Intl formatting operations itself.

Blocking on nodejs/build#4265.

[nodejs-github-bot]

Review requested:

• @nodejs/actions
• @nodejs/security-wg

[aduh95]

since we are going straight to rustc 1.88 in the build environment

Can you clarify what you mean? In this PR it looks like you're pinning to 1.86, do you mean we're switching to 1.88 on Jenkins or something else?

[Renegade334]

Yes, sorry, I meant the Jenkins infrastructure.

[richardlau]

First, a note on the update methodology. The process I've used for the manifest and cargo lockfile is somewhat different to what we were doing before, and ensures that we are mirroring the exact locked dependencies in the Chromium snapshot, in a way that should be amenable to semi-automation.

I'd like to focus more on the semi-automation. This PR changes 1821 files. #63281 changes 862. Both qualify as a large pull request (and the only reason I'm not requesting changes is that both were authored by collaborators). Furthermore we are dealing here with a module system (crates) and language (Rust) less familiar to the project.

Ideally we'd have an updater script that can be run ("standard dependency update process"). It doesn't have to be on a schedule if we don't think we're going to be regularly updating. Having an updater script would allow others to validate the update.

node/doc/contributing/large-pull-requests.md

Lines 43 to 45 in 58544fe

	* Routine dependency updates (e.g., V8, ICU, undici, uvwasi) generated by
	automation or performed by collaborators following the standard dependency
	update process.

[Renegade334]

Ideally we'd have an updater script that can be run ("standard dependency update process"). It doesn't have to be on a schedule if we don't think we're going to be regularly updating. Having an updater script would allow others to validate the update.

Yes, that was very much the motivation here. I was anticipating that there may be some feedback on this process here in this PR before committing to writing the tooling, but we can certainly do things in the opposite order. Either way, following these steps will result in an identical changeset.

I would anticipate that this would only ordinarily need to be run manually as part of a major V8 update, to bring the crates in sync with DEPS.