chore: Cache node installed via nvm on Bitrise

[Cal-L]

Description

This PR adds steps to the prep_environment workflow for both restoring and saving the installed version of node. First, we attempt to restore the cached node file path. Then the install nvm step will attempt to install node if it doesn't exist. If it does, it will use the cached version of node. Then, we cache the downloaded version of node (if there is one)

At the time of writing, node is installed to the following paths

• iOS - /Users/vagrant/.nvm
• Android - /root/.nvm

Related issues

Fixes: https://github.com/MetaMask/mobile-planning/issues/2029

Manual testing steps

1. On Bitrise, run pr_smoke_e2e_pipeline
2. On initial run, the Restore Node step in prep_environment workflow should not have any node to cache
3. nvm will then install node
4. The Save Node step will then cache node
5. Upon re-running the pr_smoke_e2e_pipeline again, Restore Node will now be able to restore the cached version of node
6. The nvm install step will then detect that a version exists and use the cached version

Screenshots/Recordings

Before

After

Build with node cache enabled - https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/6598b4fb-e88a-4252-9d57-5e8421226ea5?tab=workflows

In this build, both ios_e2e_build and android_e2e_build does not yet have node cached, so it downloads it on the respective machines and then caches it. For E2E tests - The restore node step successfully detects that node already exists via nvm and uses that instead of downloading it again

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tommasini]

LGTM!