This commit migrates the rest of Spring's test suite to JUnit Jupiter,
except spring-test which will be migrated in a separate commit.

See gh-23451

This commit migrates parameterized tests in spring-core using the
"composed @ParameterizedTest" approach. This approach is reused in
follow-up commits for the migration of the remaining modules.

For a concrete example, see AbstractDataBufferAllocatingTests and its
subclasses (e.g., DataBufferTests).

Specifically, AbstractDataBufferAllocatingTests declares a custom
@ParameterizedDataBufferAllocatingTest annotation that is
meta-annotated with @ParameterizedTest and
@MethodSource("org.springframework.core.io.buffer.AbstractDataBufferAllocatingTests#dataBufferFactories()").

Individual methods in concrete subclasses are then annotated with
@ParameterizedDataBufferAllocatingTest instead of @ParameterizedTest or
@test.

The approach makes the migration from JUnit 4 to JUnit Jupiter rather
straightforward; however, there is one major downside. The arguments
for a @ParameterizedTest test method can only be accessed by the test
method itself. It is not possible to access them in an @BeforeEach
method (see https://github.com/junit-team/junit5/issues/944).
Consequently, we are forced to declare the parameters in each such
method and delegate to a custom "setup" method. Although this is a bit
cumbersome, I feel it is currently the best way to achieve fine grained
parameterized tests within our test suite without implementing a custom
TestTemplateInvocationContextProvider for each specific use case.

Once https://github.com/junit-team/junit5/issues/878 is resolved, we
should consider migrating to parameterized test classes.

See gh-23451

This first commit for this issue:

- allows JUnit Jupiter to be used for all tests
- adds a dependency on mockito-junit-jupiter
- migrates tests in spring-core to JUnit Jupiter, except parameterized
  tests

The following script was developed in order to semi-automate the
migration process.

https://github.com/sbrannen/junit-converters/blob/master/junit4ToJUnitJupiter.zsh

See gh-23451

See gh-23282

This commit removes unused parts of the Gradle build:
* Gradle wrapper customization which should not be needed in recent
versions of Gradle (or can be replaced with options in the
gradle.properties file)
* the branch strategy configuration

See gh-23282

See gh-23282

This commit moves the compile configuration from the Gradle DSL to a
convention. This configuration is not changing often, and we're using
that opportunity to make the Java source compatibility a project
property so as to easily recent JDKs this on the command line.

See gh-23282

See gh-21778

See gh-21778

See gh-21778

ClassLoaderAwareUndeclaredThrowableStrategy fails with a VerifyError on recent JDKs after the CGLIB 3.3 upgrade. The alternative is to replace it with a plain ClassLoaderAwareGeneratorStrategy (extracted from CglibSubclassingInstantiationStrategy) and custom UndeclaredThrowableException handling in CglibMethodInvocation.

See gh-23453

Prior to this commit, the Spring Framework build would be using the
propdeps Gradle plugin to introduce two new configurations to the build:
"optional" and "provided". This would also configure related conventions
for IDEs, adding those configurations to published POMs.

This commit removes the need for this plugin and creates instead a
custom plugin for an "optional" configuration. While the Eclipse IDE
support is still supported, there is no need for specific conventions
for IntelliJ IDEA anymore.
This new plugin does not introduce the "provided" scope, as
"compileOnly" and "testCompileOnly" are here for that.

Also as of this commit, optional/provided dependencies are not published
with the Spring Framework modules POMs annymore.
Generally, these dependencies do not provide actionable information to
the developers reading / tools consuming the published POMs.

Optional/Provided dependencies are **not**:
* dependencies you can add to enable some supported feature
* dependencies versions that you can use to figure out CVEs or bugs
* dependencies that might be missing in existing Spring applications

In the context of Spring Framework, optional dependencies are just
libraries are Spring is compiling against for various technical reasons.
With that in mind, we are not publishing that information anymore.

See gh-23282

See gh-21778

See gh-21778

This commit moves the existing "test sources" Gradle plugin from Groovy
to Java and updates the "buildSrc" build file to prepare for additional
plugins in the Spring Framework build.

The plugin itself looks, for a given Spring Framework module, at all the
project dependencies for the following scopes: "compile", "testCompile",
"api", "implementation" and "optional" (to be supported by a different
plugin).

See gh-23282

See gh-23457

This commit modifies the class-level Javadoc for the @EnableWebFlux
annotation to reference an actual method in WebFluxConfigurer.

Closes gh-23457

Closes gh-23454

Closes gh-23456

Closes gh-23453

See gh-21778

This commit introduces Kotlin code snippets, for now
in the core reference documentation. Other sections
will follow, as well as improvements like global
language switch.

See gh-21778

See gh-23451

Closes gh-23450

Due to recent changes, the (bean instanceof Aware) check is now
superfluous.

See gh-23445

Closes gh-23445

This commit redeclares default methods in AbstractTestExecutionListener
in order to make them inlinable.

See gh-23435

This commit avoids unnecessary processing in the implementation of
postProcessBeforeInitialization() in ApplicationContextAwareProcessor
by immediately returning the supplied bean if it does not meet the
requirements for further processing.

Closes gh-23435

Closes gh-23436

This commit changes {@code &#42;&#47;&#42;} to <code>&#42;&#47;&#42;</code>
so that "*/*" is rendered correctly.

Closes gh-23439

Prior to this commit, the corresponding documentation was misleading.

Closes gh-23428

* pr/23437:
  Fix typo

Closes gh-23437

See gh-23437

Prior to this commit, StopWatch used System.currentTimeMillis() to
track and report running time in milliseconds.

This commit updates the internals of StopWatch to use System.nanoTime()
instead of System.currentTimeMillis(). Consequently, running time is
now tracked and reported in nanoseconds; however, users still have the
option to retrieve running time in milliseconds or seconds.

Closes gh-23235