This reverts commit 1539ba89.

This commit reorganizes tasks and scripts in the build to only apply
them where they're needed. We're considering here 3 "types" of projects
in our build:
* the root project, handling documentation, publishing, etc
* framework modules (a project that's published as a spring artifact)
* internal modules, such as the BOM, our coroutines support and our
integration-tests

With this change, we're strealining the project configuration for all
spring modules and only applying plugins when needed (typically our
kotlin support).

See gh-23282

Due to a bug (or "unintentional feature") in JUnit 4, overridden test
methods not annotated with @test are still executed as test methods;
however, JUnit Jupiter does not support that. Thus, prior to this
commit, some overridden test methods in spring-core were no longer
executed after the migration from JUnit 4 to JUnit Jupiter.

This commit addresses this issue for such known use cases, but there
are likely other such use cases within Spring's test suite.

See gh-23451

See gh-23451

WebClient, WebTestClient, and ServerResponse

The recently added body(Object) variant can be confused easily with
body(Publisher, Class) forgetting to provide the element type and
only running into the IllegalArgumentException at runtime.

See gh-23212

This commit moves the dependency management and test source files
related to integration tests to a dedicated module.
This allows us to focus the root project on building the Spring
Framework.

See gh-23282

This commit removes JDiff from the Spring Framework build and instead,
adds a Gradle plugin that configure JApiCmp tasks on the framework
modules.

Fixes gh-22942
See gh-23282

This updates brings full interoperability between Reactor and
Coroutines contexts.

Closes gh-22986

See gh-23467

* pr/23480:
  Fix typo

Closes gh-23480

See gh-23480

Closes gh-23479

The spring-build-src module does not contain any tests. Thus, we do not
need any test dependencies.

Closes gh-23467

Add `SpringJUnit5` checkstyle rule to ensure that JUnit 4 annotations
aren't accidentally used in new tests.

The "must not be public" rule has been suppressed since there are
quite a few tests that extend base tests from other packages.

Closes gh-23477

Prior to this commit, the "reactive matrix" contained a duplicate
argument set per parameterized client.

Closes gh-23476

Inspired by the fact that example.com is currently not reachable from
my network.

 Closes gh-23451

This commit migrates the spring-test test suite from JUnit 4 to JUnit
Jupiter where applicable.

Tests specific to our JUnit 4 and TestNG support remain written using
those frameworks. In addition, some tests are still written in JUnit 4
if they extend a test class that should not be migrated to JUnit
Jupiter.

See gh-23451

This commit removes the JUnit 4 dependency from all modules except
spring-test which provides explicit JUnit 4 support.

This commit also includes the following.

- migration from JUnit 4 assertions to JUnit Jupiter assertions in all
  Kotlin tests
- migration from JUnit 4 assumptions in Spring's TestGroup support to
  JUnit Jupiter assumptions, based on org.opentest4j.TestAbortedException
- introduction of a new TestGroups utility class than can be used from
  existing JUnit 4 tests in the spring-test module in order to perform
  assumptions using JUnit 4's Assume class

See gh-23451

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