Use stestr to prune its own history in CI jobs

[mtreinish]

In CI test jobs we cache the stestr timing data to provide a scheduler hint to stestr for future runs. stestr will use this to improve the distribution of tests across the workers to improve the balance of tests between the parallel workers improving throughput. However, the timing data is stored in stestr's repository (the .stestr directory in the repo) along with the subunit streams of all the previous runs. We don't need these subunit streams as they contain the full result and output from all the tests run and we won't use that for scheduling; it's mainly for local debugging purposes. These streams also can get quite large as they contain all the stdout, stderr, and logging from every test. To minimize the size of the data we're caching the CI jobs were configured to filter the stestr repository and remove the subunit streams and only leave the timing data. This was being done manually though and was likely broken on Windows. Since stestr 3.2.0 (released in 2021: https://github.com/mtreinish/stestr/releases/tag/3.2.0 ) there has been a stestr history command to manage the repository's historical subunit streams. To avoid the error prone manual filtering this just switches to use this command instead. It does require raising our lower bound on the stestr version supported for running tests. But since the release is from > 5 years ago that shouldn't be a big deal.

AI/LLM disclosure

• I didn't use LLM tooling, or only used it privately.
• I used the following tool to help write this PR description:
• I used the following tool to generate or modify code:

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[jakelishman]

One comment, but then let's check the cache size on the Windows job after this to verify before merging.

[coveralls]

Coverage Report for CI Build 26896151341

Warning

Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes.
Quick fix: rebase this PR. Learn more →

Coverage decreased (-0.04%) to 87.483%

Details

• Coverage decreased (-0.04%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 566 coverage regressions across 11 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

566 previously-covered lines in 11 files lost coverage.

Top 10 Files by Coverage Loss	Lines Losing Coverage	Coverage
crates/circuit/src/operations.rs	179	81.98%
crates/circuit/src/circuit_data.rs	110	86.55%
crates/circuit/src/packed_instruction.rs	64	87.02%
crates/qpy/src/circuit_writer.rs	50	92.79%
crates/qpy/src/py_methods.rs	38	83.21%
crates/transpiler/src/passes/high_level_synthesis.rs	35	86.65%
crates/qpy/src/value.rs	31	71.01%
crates/transpiler/src/passes/basis_translator/compose_transforms.rs	30	74.42%
crates/transpiler/src/passes/basis_translator/mod.rs	16	86.95%
crates/circuit/src/instruction.rs	10	86.87%

---

Coverage Stats

Relevant Lines:	124298
Covered Lines:	108740
Line Coverage:	87.48%
Coverage Strength:	960940.39 hits per line

---

💛 - Coveralls

[jakelishman]

Assuming this passes now, and the cache size of all the jobs is back in the ~3MB mark like we expect, this is good to go.

Thanks for fixing the apostrophe in the commit message too!

[mtreinish]

The thing I just realized (mainly because @ShellyGarion keeps reminding me to add performance release notes on my PRs). Is there a build system release note needed for the stestr version change?

[jakelishman]

Oh yeah, there is a build category you can use.

[jakelishman]

I'll remove "stable backport potential" for now just out of caution, since it's not super critical on stable/2.4, but we should consider what our policy is for build-system changes is on stable branches.