Await dynamic tests when a node's execution fails

[IWillBurn]

When Node.execute() throws after it has already submitted dynamic tests,
NodeTestTask skips DynamicTestExecutor.awaitFinished(). With parallel execution, the
node's after() behavior runs and the node is reported as finished while its dynamic
tests are still pending, so they finish after their parent or even after the test plan
(see #6141 for a reproducer). In Jupiter, this affects a @ParameterizedTest, a
@ParameterizedClass, or a DynamicContainer whose stream throws. Similarly, the
@AfterEach methods of a @TestFactory whose stream throws run while its dynamic tests
are still executing.

• NodeTestTask now awaits the submitted dynamic tests regardless of whether
  execute() threw. The original exception remains the primary failure.
• TestFactoryTestDescriptor awaits the provided dynamic tests before the after-each
  callbacks and methods, even if the stream threw. The Node#execute Javadoc now
  documents this guarantee.

The new tests in HierarchicalTestExecutorTests and ParallelExecutionIntegrationTests
fail on main with both executor service implementations. The release notes entries
are in 6.2.0-M1; I'm happy to move them to a 6.1.x patch release if you'd like to
backport the fix.

Closes #6141

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc (n/a, no new methods)
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations (no API changes; Node#execute Javadoc updated)
• Change is documented in the User Guide and Release Notes (release notes only)

[IWillBurn]

Follow-up to the latch review comment:

The latch-based tests passed CI, but replacing the sleeps with latches showed that the end-to-end tests can't reliably reproduce the bug, so I removed them. To show it, invocation a must still be running when @AfterAll starts. Releasing a in @AfterAll deadlocks with the fix (the parent waits for a), and releasing it when the arguments source fails leaves a race.

Instead, there are two deterministic tests:

• HierarchicalTestExecutorTests: a node submits a dynamic test and throws from execute(). The dynamic test is released when the node either starts waiting for it (get() on its future) or calls after(). With the fix, it finishes before after(); without it, always after. This is the NodeTestTask path shared by @ParameterizedTest, @ParameterizedClass, and DynamicContainer, so it covers all of them.
• TestFactoryTestDescriptorTests: a @TestFactory stream provides a dynamic test and then throws. The test verifies that awaitFinished() is called before the factory returns, i.e. before the after-each hooks. It's single-threaded.

I can add an end-to-end test back if you'd like, but as far as I understand, in Jupiter it can only be one of two: latch-based, which reliably passes with the fix but doesn't reliably fail without it, or time-based (sleep or timeout), which catches the bug but depends on timing.

[mpkorstanje]

I can add an end-to-end test back if you'd like, but as far as I understand, in Jupiter it can only be one of two: latch-based, which reliably passes with the fix but doesn't reliably fail without it, or time-based (sleep or timeout), which catches the bug but depends on timing.

I don't think that is necessary. It is unfortunate that we lose the illustrative examples but I don't see any seams we can use to delay the execution of the dynamic tests.

[mpkorstanje]

LGTM. Cheers, excellent pull request.

[marcphilipp]

The release notes entries
are in 6.2.0-M1; I'm happy to move them to a 6.1.x patch release if you'd like to
backport the fix.

We plan to ship 6.2.0-M1 soon. Since this bug has been present for a long time I'd say we don't need to backport it at this time.