Per #22863 (comment), this PR configures Hypothesis to ignore unexpectedly slow tests. Relative to the default of failing, this reduces flakiness due to variable performance of CI machines.

The second commit adds caching to the CI test run, so that if a CI run finds a rare but real failure that input will be replayed in future CI runs (at least until the cache expires, or the test passes and Hypothesis discards the now-passing input). This doesn't come up often, but if it does will convert flaky tests into reliable failures.

Third, we can upload the database as an "artifact" from CI and configure local runs to use that as a pull-through cache - meaning that "reproducing a failure from CI" is just "run the tests locally". No impact on flakiness but it's a rather nice workflow! 1

cc @pganssle for review / checking that it works on your machine

• Issue: Use hypothesis for testing the standard library, falling back to stubs #86275

Footnotes

1. Unfortunately the 'dump a patch with explicit examples' workflow relies on libcst and our pytest plugin - if this would be particularly interesting we can talk about making it work with unittest and perhaps even ast. ↩