In debugging WT-4608, I've worked around the stuck cache during verify by turning off timing_stress_for_tests=[split_8] for the verify portion. If I leave it off for the entire test, the test completes successfully in 10 minutes. If I turn it off for verify and then turn it back on when verify completes, for test/format's next operations loop, the test is taking a very long time.

It is no longer failing with the stuck cache, but with the timing stress the 10 minute test has grown more than an order of magnitude to more than 2 hours (and it isn't finished yet).

Looking at the database directory and pmp I can see the test is still running. It is not hung on anything. But there is always a thread (eviction thread) sleeping in the timing stress function. The user thread(s) are usually waiting on the cache.

We should evaluate and perhaps conditionalize when to set or unset the timing stress settings in test/format.