chore: Prevent reusing Yarn cache across Yarn versions

[Gudahtt]

Description

The Yarn cache will no longer be reused across Yarn versions in our CircleCI pipeline. This should prevent bugs in the event that the lockfile format changes again, or the checksum method used by Yarn.

We saw this problem when we upgraded from Yarn v3 to v4 on our main branch. We prepared a backport release that was still using v3, and it resulted in lockfile errors that we didn't catch until 2 releases later.

Manual testing steps

See that CI completes successfully using the correct cache key

Related issues

None

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've clearly explained:
  • What problem this PR is solving.
  • How this problem was solved.
  • How reviewers can test my changes.
• I’ve indicated what issue this PR is linked to: Fixes #???
• I’ve included tests if applicable.
• I’ve documented any added code.
• I’ve applied the right labels on the PR (see labeling guidelines).
• I’ve properly set the pull request status:
  • In case it's not yet "ready for review", I've set it to "draft".
  • In case it's "ready for review", I've changed it from "draft" to "non-draft".

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.

[Gudahtt]

A file was used here rather than an environment variable because CircleCI doesn't support referencing dynamically-set environment variables from restore_cache keys. It only works for environment variables set statically for the entire workflow.

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (5fffa65) 68.39% compared to head (a80c3b1) 68.39%.
Report is 1 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop   #21046   +/-   ##
========================================
  Coverage    68.39%   68.39%           
========================================
  Files         1007     1007           
  Lines        40252    40252           
  Branches     10764    10764           
========================================
  Hits         27529    27529           
  Misses       12723    12723           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[metamaskbot]

Builds ready [a80c3b1]

• builds: chrome, firefox
• builds (beta): chrome
• builds (flask): chrome, firefox
• builds (MMI): chrome, firefox
• build viz: Build System
• mv3: Background Module Init Stats
• mv3: UI Init Stats
• mv3: Module Load Stats
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• code coverage: Report
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4
  • common: 0, 1, 2, 3, 4, 5, 6
  • content-script: 0
  • contentscript: contentscript
  • disable-console: disable-console
  • inpage: inpage
  • policy-load: policy-load
  • sentry-install: sentry-install
  • ui: 0, 1, 10, 11, 12, 2, 3, 4, 5, 6, 7, 8, 9

Page Load Metrics (1516 ± 396 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	88	205	133	34	16
		domContentLoaded	84	203	127	34	16
		load	99	2512	1516	826	396
		domInteractive	84	203	127	34	16

Bundle size diffs

• background: 0 Bytes (0.00%)
• ui: 0 Bytes (0.00%)
• common: 0 Bytes (0.00%)

[HowardBraham]

@Gudahtt @brad-decker @FrederikBolding I think there's a problem with this PR actually, because now we're restoring cache from
dependency-cache-{{ checksum "/tmp/YARN_VERSION" }}-{{ checksum "yarn.lock" }}
but saving cache to
dependency-cache-v1-{{ checksum "yarn.lock" }}
Thus, nothing ever comes back from the cache

[Gudahtt]

Thanks @HowardBraham , good catch!