[omnibus] Speed up gitlab ci runs

Combining #3386448: Get rid of InstallUninstallTest and #3386479: Copy less files around in ComponentsIsolatedBuildTest to see what the effect is.

https://git.drupalcode.org/project/drupal/-/jobs/82114 - 7m49s down from over 10 minutes.

https://git.drupalcode.org/project/drupal/-/jobs/82113 - 8m21s down from over 10 minutes.

Possible next candidates:

Drupal\Tests\config_translation\Functional\ConfigTranslation takes a long time to come back by the looks of things.

I've made some modifications to the pipeline config again:

1. Removed parallel from kernel tests, because often the three kernel test runners end up waiting for gitlab pods which doesn't help them finish quicker.

2. Reduced functional test concurrency down to six - without InstallUninstallTest functional tests can finish quicker/about the same time as nightwatch/functional javascript/build tests.

By doing #1 and #2, the overall pipeline looks like the following:

1. composer and yarn
2. Linting, unit tests, kernel tests
3. All other test types.

We use exactly 10 jobs for #3, which means it maxes out the concurrency limit but also minimises queuing time. However it's only an improvement on the current gitlab MR once those two tests are dealt with, so marking PP-3.

Last commits make phpunit parallel 2, and reduce the functional tests parallel by one.

This doesn't improve the overall run time, 14m30s is a touch slower but probably margin of error, however if we're able to resolve the kubernetes pod not available issues, it might speed things up by compressing the blocking unit tests step so that it definitely finishes alongside the lint jobs.

The issue with the parallel_tests approach for us with the current setup is that we're only parallelizing functional tests (and in this issue, unit tests, but those are pretty well matched for times already). The other test types take about as long as the parallelized functional tests and we can't go over ten job concurrency or we end up with queueing.

If we changed the approach and did something like parallelizing all functional, functional javascript, and build tests together, (possibly include kernel tests too) then it might be a further improvement though.

13 minutes.

https://git.drupalcode.org/project/drupal/-/pipelines/20725

With install/uninstall test and the nightwatch composer test optimisations applied, the bottleneck moves to functional javascript tests.

With parallel 2 these take 9 and 7 minutes respectively https://git.drupalcode.org/project/drupal/-/jobs/93117 https://git.drupalcode.org/project/drupal/-/jobs/93118. This is not really an improvement on parallel 1 so it is probably another test that individually takes a very long time.

However nightwatch doesn't use parallel or run-tests.sh and takes about 8 minutes too, we'd need to run those in parallel to get under this, but that seems possible: https://nightwatchjs.org/guide/running-tests/parallel-running.html

I have the same question as #17.

There's also an explicit 'start apache' step in the pipeline which we can remove at least for unit/kernel tests which is just a few seconds at most but worth cleaning up, only worth doing if we keep the same images though.

#3388375: Run nightwatch tests in parallel should remove the nightwatch bottleneck.

Also incorporating #3388365: Distribute @group #slow tests between test runners and mark more tests.

10m27s with the current patch set https://git.drupalcode.org/project/drupal/-/pipelines/21810

Current state of the combined MR has us at around 11 minutes: https://git.drupalcode.org/project/drupal/-/pipelines/22188

Biggest thing I'm learning here is that once some of the issues already opened are applied, there is a hard bottleneck of specific long-running tests which break any attempts to optimize concurrency or use parallel runners, and skew perceived performance when CPUs are constrained or concurrency reduced, because they always take a long time to run.

Opened #3389281: [meta] Refactor ultra-slow tests.

Nothing individually committable from here any more, just merging all the current work into it to see overall progress.

I am pretty sure that was working until we moved linting to the parent jobs.

Same issue with unit, kernel, and functional tests in the child jobs, they could also start as soon as composer finishes.

They only depend on composer, not yarn, so not clear to me what changed.

11 minutes, 1 second:

https://git.drupalcode.org/project/drupal/-/pipelines/24323

@mstrelan, good point, it used to work like that, issue here: #3390073: Use 'needs' instead of 'dependencies' to speed up gitlab CI jobs and run phpstan first

Opened #3462762: [meta] Core test suite performance to have more of a proper meta for test suite performance improvements, this was more of a sandbox issue so is very messy.