fix(ci): Expand cached state disks before running tests

[teor2345]

Motivation

In PR #4945, we increased the cached state disk size to 200GB. But that only applies to newly created cached states. (Which take 24 hours to run, and still need fixes like PR #4961.)

So we want to expand older cached state disks to the latest size before using them.

Also fixes #4295.

Solution

• Grow the disk partition to the full disk size
• Resize the filesystem to the full partition size
• Actually run the test

Related fixes:

• Keep cached state image names within the 63-character google cloud limit (bugfix on PR fix(ci): Write cached state images after update syncs, and use the latest image from any commit #4949)
• Adapt cached state image search for short branch names by ignoring branch names (just use short commit hashes)

Review

This is urgent because it's stopping all the other PRs from passing.

Reviewer Checklist

• CI passes

[gustavovalverde]

This was a great finding! Thank you!

[gustavovalverde]

This PR is failing as the disk name is too long. I'll be fixing this so we're able to continue with this merge https://github.com/ZcashFoundation/zebra/runs/8050845710?check_suite_focus=true#step:9:75

[teor2345]

This PR is failing as the disk name is too long. I'll be fixing this so we're able to continue with this merge https://github.com/ZcashFoundation/zebra/runs/8050845710?check_suite_focus=true#step:9:75

@gustavovalverde I'm happy to fix it, I have a format that will come in under the 63 character limit, but still be unique.

[gustavovalverde]

Oh, I think we were working on the disk name solution in parallel. I have a PR with a similar solution here: #4966

I don't mind if your prefer your solution, but please take into consideration some of the examples I made there as, following the actual name reference in this PR (${{ inputs.disk_prefix }}-${SHORT_GITHUB_REF}-${{ env.GITHUB_SHA_SHORT }}-v${{ env.STATE_VERSION }}-${{ env.NETWORK }}-${{ inputs.disk_suffix }}${UPDATE_SUFFIX}-${TIME_SUFFIX}) a disk exceeding 63 characters would be possible, for example:

• zebrad-cache-4962-merge-e098efa-v25-mainnet-checkpoint-update-2022-08-27-14-04-40 (81 characters)

Also, keeping the commit does not seem necessary as explained in #4966 as the GITHUB_REF should be enough to find the latest available disk from the PR/branch

[teor2345]

Oh, I think we were working on the disk name solution in parallel. I have a PR with a similar solution here: #4966

Sorry about that, but I'm happy to be responsible for fixing this one.

I don't mind if your prefer your solution, but please take into consideration some of the examples I made there as, following the actual name reference in this PR (${{ inputs.disk_prefix }}-${SHORT_GITHUB_REF}-${{ env.GITHUB_SHA_SHORT }}-v${{ env.STATE_VERSION }}-${{ env.NETWORK }}-${{ inputs.disk_suffix }}${UPDATE_SUFFIX}-${TIME_SUFFIX}) a disk exceeding 63 characters would be possible, for example:

• zebrad-cache-4962-merge-e098efa-v25-mainnet-checkpoint-update-2022-08-27-14-04-40 (81 characters)

This doesn't actually happen with the latest code in this PR, because:

• the checkpoint is at a fixed height, so it is never updated
• the update suffix is "-u"
• the date doesn't have a year or hyphens

So the actual longest branch name is 63 characters:

• zebrad-cache-4962-merge123-e098efa-v25-mainnet-tip-u-0827140440

Also, keeping the commit does not seem necessary as explained in #4966 as the GITHUB_REF should be enough to find the latest available disk from the PR/branch

Since the branch name is truncated, it's no longer unique, but bug #4842 and accurate search require it to be unique.