ci: try default cache in depot

[joroshiba]

Summary

Migrates away from buildjet cache, and updates to latest rust cache handler action.

Background

The buildjet cache seems to hit random slowdowns, and we aren't using their servers anymore. According to docs, depot runners default to using local cache mechanisms. This attempts using those.

Testing on this PR show that it performs a little faster than latest runs on mainnet (5s on cached vs 8s on most recent main test run), and hopefully avoids the occasional slowdown we have seen where tests can take over 30m.

[greptile-apps]

Greptile Summary

This PR migrates the CI workflow from using buildjet cache to depot's default local cache mechanisms and updates the rust-cache action to the latest version. The changes remove the explicit cache-provider: "buildjet" configuration from most rust-cache steps throughout the .github/workflows/test.yml file, allowing depot runners to use their built-in local caching. Additionally, the rust-cache action is updated from v2.7.8 to v2.8.0 to incorporate the latest improvements.

The motivation behind this change is to address performance issues with buildjet cache, which has been experiencing random slowdowns that can cause test runs to exceed 30 minutes. According to depot's documentation, their runners provide faster local cache mechanisms by default. Early testing shows improved performance with cached builds completing in 5 seconds versus 8 seconds on the main branch.

This change integrates well with the existing CI infrastructure since depot runners are already being used, and the modification simply leverages their recommended caching approach rather than relying on an external cache provider that's no longer optimal for the project's needs.

Confidence score: 3/5

• This PR is moderately safe to merge but has one inconsistency that should be addressed before merging.
• The score reflects a configuration inconsistency where one job still uses the old rust-cache version and github cache provider, which could lead to inconsistent caching behavior across jobs.
• The lockfile job at lines 111-113 needs attention as it still uses Swatinem/[email protected] with cache-provider: "github" while all other jobs have been updated to v2.8.0 without explicit cache provider configuration.

_{1 file reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}

[joroshiba]

This PR is stale because it has been open 45 days with no activity. Remove stale label or this PR will be
closed in 7 days.

[joroshiba]

This PR was closed because it has been stale.