Lower default concurrency to 8
Problem/Motivation
Follow-up from #3450701: Add a variable for run-tests.sh concurrency, default stays at 32 and #3450616: Optimize test order when --directory is used. And based on findings from #3469687: Reduce CPU requirements for core gitlab pipelines.
When contrib tests are run with concurrency, they're run in 'test type alphabetical order', which means that functional and functional js tests run first, then kernel tests, then unit tests.
This means that if a module has one functional test that takes 30 seconds, and 3 kernel tests that take 10 seconds each, the kernel tests can all be run one after the other while the functional test is going.
Currently, the concurrency variable is set quite high (32), and the CPU request is set quite low (2).
If a module has exactly 32 tests, with a mixture of functional, kernel, and unit tests, this means that all of those tests would start at the same time, maximising the CPU usage at the beginning of the job, and then the kernel and unit tests will finish within 1-5 seconds each, and then the functional tests will keep running for another 20-30 seconds afterwards at effectively 1-2 concurrency.
If a module has a larger number of functional js and functional tests, then running them all together at the same time could result in them all collectively running slower and resulting in the job taking overall longer to run.
This is going to be very hard to test and verify, but if a module with a moderately large test base finishes in the same or less time after the change, then it's not doing any harm.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Related issue: Issue #3497431
Related issue: Issue #3450701