release-25.2: roachtest: randomize volume type and XFS

[golgeek]

Backport 1/1 commits from #159010.

/cc @cockroachdb/release

---

Prior to this patch, tests had three possiblities for volume types:

1. Specify PreferLocalSSD() DisableLocalSSD() options.
2. Force a specific volume type via VolumeType() (volume type being provider specific, this was only possible for tests that target a single provider).
3. Rely on the default behavior for PreferLocalSSD() and use the default volume type in roachprod for the provider in case local SSD was not selected.

The way PreferLocalSSD() was implemented meant that most of the tests were actually running on local SSDs (when available on the machine type), leading to a gap in the testing strategy with regards to volume types.

This patch brings the new ClusterSpec option RandomizeVolumeType(). In case volume type is not forced and neither PreferLocalSSD() or DisableLocalSSD() are specified, specifying RandomizeVolumeType() will take precendence over the --local-ssd argument and will randomly select a volume type from those available in the targeted provider:

• AWS: gp3, io2, local SSD
• GCE: pd-ssd, local SSD
• Azure: premium-ssd, premium-ssd-v2, ultra-disk, local SSD
• IBM: 10iops-tier

Note: volume type randomization gives the same weight to all options.

This patch also introduces a random chance of provisioning XFS as a filesystem via the option RandomlyUseXfs().
The option is built in the same way as RandomlyUseZfs(), granting a 20% chance of XFS if present.
If both RandomlyUseZfs() and RandomlyUseXfs() are used, they both get a 20% chance, leaving 60% chance for the default ext4.

All/most of the KV tests, and a few admission-control are switched to volume type/filesystem randomization as requested in this issue.

Epic: none
Fixes: 146661
Release note: None

Release justification: test change only

[blathers-crl]

Thanks for opening a backport.

Before merging, please confirm that it falls into one of the following categories (select one):

• Non-production code changes. Includes test-only changes, build system changes, etc.
• Fixes for serious issues. Defined in the policy as correctness, stability, or security issues, data corruption/loss, significant performance regressions, breaking working and widely used functionality, or an inability to detect and debug production issues.
• Other approved changes. These changes must be gated behind a disabled-by-default feature flag unless there is a strong justification not to.

Add a brief release justification to the PR description explaining your selection.

Also, confirm that the change does not break backward compatibility and complies with all aspects of the backport policy.

All backports must be reviewed by the TL and EM for the owning area.

[cockroach-teamcity]

This change is 

[blathers-crl]

✅ PR #160033 is compliant with backport policy

Confidence: high
Backward compatible: true
Explanation: The PR is compliant with the CockroachDB backport policy as it only applies to non-production files. The files modified are in the directories pkg/cmd/roachtest/ and pkg/roachprod/, which fall under the category of development tools and testing infrastructure. According to the policy, changes affecting non-production code, tests, or development tools are exempt from the requirements of critical bug justifications or feature flag gating. Additionally, the PR body explicitly states 'Release justification: test change only', which complies with the exception for release justification allowing changes for explicitly reviewed and approved backporting. There is no indication of security-related changes, and the changes appear to only affect the testing behavior without modifying actual database functionality or introducing breaking changes.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}