[JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.

It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.

Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.

The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.