Issue: SPR-16369

Issue: SPR-16369

Based on IntelliJ IDEA 2017.3 introspection results.

Issue: SPR-15756

This commit introduces the following changes.

1) It adds a new Spring @NonNull annotation which allows to apply
@NonNullApi semantic on a specific element, like @Nullable does.
Combined with @Nullable, it allows partial null-safety support when
package granularity is too broad.

2) @Nullable and @NonNull can apply to ElementType.TYPE_USE in order
to be used on generic type arguments (SPR-15942).

3) Annotations does not apply to ElementType.TYPE_PARAMETER anymore
since it is not supported yet (applicability for such use case is
controversial and need to be discussed).

4) @NonNullApi does not apply to ElementType.FIELD anymore since in a
lot of use cases (private, protected) it is not part for the public API
+ its usage should remain opt-in. A dedicated @NonNullFields annotation
has been added in order to set fields default to non-nullable.

5) Updated Javadoc and reference documentation.

Issue: SPR-15756

Issue: SPR-15869

This commit revises the implementation of the SpringExtension to use
the getRequired*() methods in the ExtensionContext which are now built
into JUnit Jupiter thanks to inspiration from the initial "convenience"
methods implemented here.

Issue: SPR-15720
Issue: SPR-15792

Issue: SPR-15728

This commits extends nullability declarations to the field level, formalizing the interaction between methods and their underlying fields and therefore avoiding any nullability mismatch.

Issue: SPR-15720

This commit also removes nullability from two common spots: ResolvableType.getType() and TargetSource.getTarget(), both of which are never effectively null with any regular implementation. For such scenarios, a non-null empty type/target is the cleaner contract.

Issue: SPR-15540

Issue: SPR-15540

This commit introduces 2 new @Nullable and @NonNullApi
annotations that leverage JSR 305 (dormant but available via
Findbugs jsr305 dependency and already used by libraries
like OkHttp) meta-annotations to specify explicitly
null-safety of Spring Framework parameters and return values.

In order to avoid adding too much annotations, the
default is set at package level with @NonNullApi and
@Nullable annotations are added when needed at parameter or
return value level. These annotations are intended to be used
on Spring Framework itself but also by other Spring projects.

@Nullable annotations have been introduced based on Javadoc
and search of patterns like "return null;". It is expected that
nullability of Spring Framework API will be polished with
complementary commits.

In practice, this will make the whole Spring Framework API
null-safe for Kotlin projects (when KT-10942 will be fixed)
since Kotlin will be able to leverage these annotations to
know if a parameter or a return value is nullable or not. But
this is also useful for Java developers as well since IntelliJ
IDEA, for example, also understands these annotations to
generate warnings when unsafe nullable usages are detected.

Issue: SPR-15540

Closes gh-1361

Issue: SPR-15340

Prior to this commit, when using @EnabledIf or @DisabledIf in Spring's
JUnit Jupiter support, the test's ApplicationContext was always eagerly
loaded, even if the ApplicationContext would never be used (i.e., the
test was disabled). This behavior can lead to undesirable side effects
-- for example, attempting to load an application context that requires
services only available on the CI server when the test is not actually
running on the CI server.

This commit addresses this issue by introducing new boolean
`loadContext` flags in @EnabledIf and @DisabledIf. By default these
flags are set to false which means that the user's test application
context will not be loaded to evaluate the expression. On the contrary,
a dummy application context will be loaded instead, and expressions
will be evaluated against that dummy context. Consequently, if the user
wishes to interact with properties from the Spring Environment or with
beans from the test application context, the `loadContext` must be
explicitly set to true.

In addition, expressions which evaluate to a String must now evaluate
to exactly "true" or "false" (ignoring case and surrounding whitespace).

Issue: SPR-14649

This commit improves the exception message thrown when a test's
ApplicationContext is no longer active by explaining that the cause
may be due to parallel test execution.

Issue: SPR-5863

Issue: SPR-5863

Prior to this commit, executing tests concurrently in the TestContext
Framework (TCF) was unsupported and typically lead to unpredictable
results.

This commit addresses this core issue by supporting concurrent
execution in the TestContextManager and the DefaultTestContext.

Specifically, the TestContextManager now uses ThreadLocal storage for
the current TestContext, thereby ensuring that any registered
TestExecutionListeners and the TestContextManager itself operate on a
TestContext specific to the current thread.

In order to avoid repeatedly incurring the costs of the overhead of the
TCF bootstrapping process, the original TestContext built by the
TestContextBootstrapper is used as a template which is then passed to
the copy constructor of the concrete implementation of the TestContext
to create the context for the current thread. DefaultTestContext now
implements such a copy constructor, and all concrete implementations of
TestContext are encouraged to do the same.

If the TestContext built by the TestContextBootstrapper does not
provide a copy constructor, thread-safety and support for concurrency
are left completely to the implementation of the concrete TestContext.

Note, however, that this commit does not address any thread-safety or
concurrency issues in the ContextLoader SPI or its implementations.

Issue: SPR-5863

This commit inlines the basic implementation of AttributeAccessorSupport
and converts the LinkedHashMap to a ConcurrentHashMap.

In addition, attributes are now included in toString().

Issue: SPR-5863

Replace manual synchronization block in SpringClassRule with Java 8's
Map.computeIfAbsent().

Issue: SPR-12421

This commit picks up where SPR-14614 left off by introducing a new
@EnabledIf annotation to serve as a logical companion to @DisabledIf.

In addition, this commit extracts common logic from DisabledIfCondition
into a new AbstractExpressionEvaluatingCondition base class which the
new EnabledIfCondition also extends.

An @EnabledOnMac annotation is also included in the Javadoc as well as
in the test suite to demonstrate support for custom composed annotations.

Issue: SPR-14644

Prior to this commit, the DisabledIfCondition did not trim whitespace
from expressions configured via @DisabledIf. Consequently, results such
as "  true  " would evaluate to "false".

This commit fixes this problem by trimming all expressions configured
via @DisabledIf.

Issue: SPR-14614

This commit ensures that a user provides a non-empty expression in
declarations of @DisabledIf.

Issue: SPR-14614

- Extracted stand-alone DisabledIfCondition from the SpringExtension
  so that the condition is only evaluated when necessary.

- Simplified implementation of DisabledIfCondition.

- Overhauled and extended logging in DisabledIfCondition.

- DisabledIfCondition now throws an IllegalStateException if @DisabledIf
  is not present on the test element or if the expression does not
  evaluate to a String or Boolean.

- Each generated ConditionEvaluationResult now includes the actual
  expression in the default reason.

- @DisabledIf is now auto-configured to be evaluated by the
  DisabledIfCondition since it is now meta-annotated with
  @ExtendWith(DisabledIfCondition.class)

- Overhauled documentation for @DisabledIf and provided standard
  examples as well as an @DisabledOnMac annotation to demonstrate
  support for custom composed annotations.

Issue: SPR-14614

This commit introduces @DisabledIf annotation that takes SpEL as a
condition.  The condition is evaluated at run time whether to disable
JUnit 5 (Jupiter) test method/class.

Issue: SPR-14614

(cherry picked from commit 35e247aa)