Test discovery: Make classpath scanning fallback configurable

[OliverO2]

Fixes #3973.

Introduces a system property
"kotest.framework.discovery.classpath.scanning.enabled",
defaulting to "true".

This exists to work around a Gradle bug which occurs with JunitPlatform
and maxParallelForks > 1 (process parallelization). In this case,
depending on the number of CPU cores, Gradle may invoke all but one
Kotest launchers with a non-empty list of class selectors, and the
remaining Kotest launcher with an empty list of class selectors,
triggering a classpath scan in Kotest. In that case, tests will execute
twice (discovered once via a class selector, a second time via the
classpath scan).

Also makes Kotest-internal debug logging multi-process-aware,
naming log files like "kotest-PID.log", containing the respective
process id.

[sksamuel]

Fixes #3973.

Introduces a system property "kotest.framework.discovery.classpath.scanning.enabled", defaulting to "true".

This exists to work around a Gradle bug which occurs with JunitPlatform and maxParallelForks > 1 (process parallelization). In this case, depending on the number of CPU cores, Gradle may invoke all but one Kotest launchers with a non-empty list of class selectors, and the remaining Kotest launcher with an empty list of class selectors, triggering a classpath scan in Kotest. In that case, tests will execute twice (discovered once via a class selector, a second time via the classpath scan).

Also makes Kotest-internal debug logging multi-process-aware, naming log files like "kotest-PID.log", containing the respective process id.

If it sends all but one a non empty list, how does the maxParallelForks do anything? Does it just spawn multiple kotest's that don't do anything?

[OliverO2]

If it sends all but one a non empty list, how does the maxParallelForks do anything? Does it just spawn multiple kotest's that don't do anything?

It spawns multiple Kotests (each in its own JVM). Then almost all of them get a non-empty list of classes, so these Kotest's do their stuff. Just (the last?) one gets an empty list and (with this PR) does nothing (instead of doing a classpath scan and running all tests again). Seems like a classical "off by one" error in Gradle's Java test task.

More detailed description here: #3973 (comment)

Considerations here: #3973 (comment)

#3973 shows how the drama unfolds.

[Kantis]

Should we consider moving to making classpath scanning disabled unless the ClasspathRootSelector is included? Perhaps adding a fat warning when there's no selectors at all stating that this default will be changing in 6.0?