Execution mode is needlessly coarsened

[mpkorstanje]

Step to reproduce

Originally reported at: cucumber/cucumber-jvm#2589.

Given a tree of test descriptors where one test declares a global resource lock:

|- Container A
| |- Test 1 ( .getExclusiveResources() => GLOBAL_READ_WRITE )
| |- Test 2
| \- Test 3
\- Container B
  |- Test 4
  |- Test 5
  \- Test 6

When executed in parallel Container A is executed with ExecutionMode.SAME_THREAD. This reduces the efficiency of parallel execution somewhat as the serial part of the execution now also includes tests 2 and 3.

Analysis

The same thread execution mode is applied to a container if any of its children has a GLOBAL_READ_WRITE lock:

https://github.com/junit-team/junit5/blob/5fdb138924f59703a6a4fcd0cdcde6d1a224a950/junit-platform-engine/src/main/java/org/junit/platform/engine/support/hierarchical/NodeTreeWalker.java#L73-L76

The rationale for this behaviour is given in #2038 (comment):

The (pessimistic) assumption behind forcing children of containers with resource locks to use execution mode SAME_THREAD is that the resource might not be safe to access in e.g. @BeforeAll methods and in different threads from @Test methods. Thus it's not the same as having @ResourceLock on every @Test method. IIRC we had a similar issue for @Execution only applying to methods while being declared on the class level.

While this is true for JUnit Jupiter, this is not the case for Cucumber. In Cucumber containers do not execute any hooks.

Providing containers with a way to signal that they are mere containers would allow the coarsened execution mode to be applied more selectively.