See gh-23451

Closes gh-23476

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 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-23451

Since arbitrary levels of proxies do not occur, this commit replaces
the `while` loop in SerializableTypeWrapper.unwrap() with a simple
`if` statement.

Closes gh-23415

Prior to this commit, AnnotationAttributes#assertNotException checked if
the attribute value was an instance of Exception. Although this was
typically sufficient, the scope was not always broad enough -- for
example, if AnnotationReadingVisitorUtils#convertClassValues stored a
Throwable in the map (such as a LinkageError).

This commit fixes this by checking for an instance of Throwable in
AnnotationAttributes#assertNotException.

Closes gh-23424

Deprecate all mutation methods in `MethodParameter` in favor of factory
methods that return a new instance. Existing code that previously relied
on mutation has been updated to use the replacement methods.

Closes gh-23385

Prior to this commit, the new `TYPE_HIERARCHY_AND_ENCLOSING_CLASSES`
annotation search strategy failed to find annotations on enclosing
classes if the source class was a nested class that itself had no
annotations present.

This commit fixes this by adding special logic to AnnotationsScanner's
isWithoutHierarchy() method to properly support nested classes.

Closes gh-23378

Add a `TYPE_HIERARCHY_AND_ENCLOSING_CLASSES` annotation search strategy
that can be used to search the full type hierarchy as well as any
enclosing classes.

Closes gh-23378

Rename `SearchStrategy.EXHAUSTIVE` from `MergedAnnotations` to
`SearchStrategy.TYPE_HIERARCHY`

See gh-23378

See gh-23352

Closes gh-23352

See gh-23300

Closes gh-23300

See gh-23321

Fix `isAssignable` for `ResolvableType.forRawClass` so that it can be
used with types backed by a `TypeVarible`. Prior to this commit the
rawClass value was used, which wouldn't always work.

Closes gh-23321

Closes gh-23317

This commit introduces the DataBufferWrapper, a wrapper for DataBuffers,
and uses it in applicable use cases.

DataBuffers::split (and underlying algorithm) should not be returning
a Flux<DataBuffer>, but rather a Flux<Flux<DataBuffer>>. In other words,
it should not join all data buffers that come before a delimiter.

Providing an implementation of a such a fully reactive split method
proved to be beyond the scope of this release, so this commit removes
the method altogether.

Closes gh-23208

See gh-23187

Closes gh-23191

See gh-23187

This commit adds two methods to DataBufferUtils:
- one that reads a Flux<DataBuffer> from a Path
- one that writes a Flux<DataBuffer> to a Path

Closes gh-22957

This commit introduces an internal SortedProperties class that is a
specialization of java.util.Properties which sorts properties
alphanumerically based on their keys.

This can be useful when storing a java.util.Properties instance in a
properties file, since it allows such files to be generated in a
repeatable manner with consistent ordering of properties.

Comments in generated properties files can also be optionally omitted.

An instance of SortedProperties can be created via two new
createSortedProperties() factory methods in
org.springframework.core.CollectionFactory.

Closes gh-23018

Rename some `MergedAnnotation` methods to prevent using parent/child
terminology, specifically:

	`getDepth()` has been renamed `getDistance()`
	`getParent()` has been renamed `getMetaSource()`
	`getTypeHierarchy()` has been renamed `getMetaTypes()`

The parent child naming was particularly confusing given that the
parent/child relationships were inverted from the way that a lot of
users think about meta-annotations. For example, a `@RequestMapping`
having a parent of `@GetMapping` feels odd given that `@GetMapping`
is the thing declaring the meta-annotation relationship.

The new method names are designed to align more closely with existing
terms. For example, `getMetaSource` hints at the relationship with
`isMetaAnnotated` and `getSource`.

Closes gh-22946

Migrate all existing JUnit 4 `assert...` based assertions to AssertJ
and add a checkstyle rule to ensure they don't return.

See gh-23022

Migrate all existing `assertThat(..., Matcher)` assertions to AssertJ
and add checkstyle rules to ensure they don't return.

See gh-23022

See gh-22959

Migrate tests that use `@test(expectedException=...)` or
`try...fail...catch` to use AssertJ's `assertThatException`
instead.

* Added DataBufferUtils.split variant that takes multiple delimiters
  as argument (instead of 1).
* Use this new split() variant from within StringDecoder, replacing
  its inefficient algorithm with the Knuth-Morris-Pratt algorithm.

org.junit.Assert.assertThat() is deprecated as of JUnit 4.13.

See gh-22894