fix #944: provide the resolved parameters in the ExtensionContext

[t1]

Overview

As (almost) suggested in #944, I've added a method ExtensionContext#getResolvedParameters (and getRequiredResolvedParameters) and an interface ResolvedParameters. The AbstractExtensionContext can store and return those. The ParameterResolutionUtils store them, but I had to introduce another but internal interface ResolvedParametersStore to make this possible without hurting the visibility scopes between descriptor and execution.

The problem I ran into is that TestMethodTestDescriptor#execute calls the parameter resolvers after all BeforeEach callbacks and methods. So they can't see them, but that was the purpose of it all.

I'm not sure, if this ordering could be inverted: first the parameter resolvers, then the BeforeEach handling.

---

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
• 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
• Change is documented in the User Guide and Release Notes

[marcphilipp]

Thanks for the PR! I'll bring this up with the team to discuss the high-level design before we get too deep.

I'm not sure, if this ordering could be inverted: first the parameter resolvers, then the BeforeEach handling.

Yes, I think we'd have to explicitly resolve the test method's parameters (and only those!) before calling any method-level extensions or lifecycle callbacks.

[marcphilipp]

This would also record parameters for methods invoked via ExtensionContext.getExecutableInvoker(), right? I think we need to ensure that we only record them for the test method that's being executed, e.g. by checking executable equals extensionContext.getTestMethod().

[marcphilipp]

Is there a benefit of recording these one-by-one rather than in a single go?