Issue: SPR-14645

Latest dependency updates (Undertow 1.4.3, EhCache 3.1.2, Caffeine 2.3.3, Rome 1.7, Woodstox 5.0.3, Jettison 1.3.8, JRuby 9.1.5.0, RxJava 2.0 RC2, RxNetty 0.5.2 RC4)

Issue: SPR-13965

A straight-forward port of the resource handling support in
spring-webmvc to spring-web-reactive. Primarily adapting contracts and
implementations to use the reactive request and response and the
reactive ResourceHttpMessageWriter.

Issue: SPR-14521

Issue: SPR-14421

This commit adds a "spring-context-indexer" module that can be added to
any project in order to generate an index of candidate components defined
in the project.

`CandidateComponentsIndexer` is a standard annotation processor that
looks for source files with target annotations (typically `@Component`)
and references them in a `META-INF/spring.components` generated file.

Each entry in the index is the fully qualified name of a candidate
component and the comma-separated list of stereotypes that apply to that
candidate. A typical example of a stereotype is `@Component`. If a
project has a `com.example.FooService` annotated with `@Component` the
following `META-INF/spring.components` file is generated at compile time:

```
com.example.FooService=org.springframework.stereotype.Component
```

A new `@Indexed` annotation can be added on any annotation to instructs
the scanner to include a source file that contains that annotation. For
instance, `@Component` is meta-annotated with `@Indexed` now and adding
`@Indexed` to more annotation types will transparently improve the index
with additional information. This also works for interaces or parent
classes: adding `@Indexed` on a `Repository` base interface means that
the indexed can be queried for its implementation by using the fully
qualified name of the `Repository` interface.

The indexer also adds any class or interface that has a type-level
annotation from the `javax` package. This includes obviously JPA
(`@Entity` and related) but also CDI (`@Named`, `@ManagedBean`) and
servlet annotations (i.e. `@WebFilter`). These are meant to handle
cases where a component needs to identify candidates and use classpath
scanning currently.

If a `package-info.java` file exists, the package is registered using
a "package-info" stereotype.

Such files can later be reused by the `ApplicationContext` to avoid
using component scan. A global `CandidateComponentsIndex` can be easily
loaded from the current classpath using `CandidateComponentsIndexLoader`.

The core framework uses such infrastructure in two areas: to retrieve
the candidate `@Component`s and to build a default `PersistenceUnitInfo`.
Rather than scanning the classpath and using ASM to identify candidates,
the index is used if present.

As long as the include filters refer to an annotation that is directly
annotated with `@Indexed` or an assignable type that is directly
annotated with `@Indexed`, the index can be used since a dedicated entry
wil be present for that type. If any other unsupported include filter is
specified, we fallback on classpath scanning.

In case the index is incomplete or cannot be used, The
`spring.index.ignore` system property can be set to `true` or,
alternatively, in a "spring.properties" at the root of the classpath.

Issue: SPR-11890

This commit adds support for RxJava 2 Completable,
Single, Observable and Flowable types (io.reactivex package).

Issue: SPR-14628

Due to restrictions imposed by JUnit 4, the SpringClassRule must be
declared as a public static field, which makes it impossible to be
declared directly within a nested (i.e., inner) test class.

This commit demonstrates a work-around that makes it possible to use
the SpringClassRule and SpringMethodRule in a nested (i.e., inner) test
class when using a custom JUnit 4 runner such as the
HierarchicalContextRunner from Stefan Bechtold.

The trick is to have inner test classes extend a class that properly
declares the SpringClassRule and SpringMethodRule. The
SpringRuleConfigurer in this commit serves as an example.

Note, however, that each such nested test class must declare its own
@ContextConfiguration. Furthermore, TestExecutionListeners in the
Spring TestContext Framework are not applied to the enclosing instance
of such an inner test class, meaning that @Autowired fields in the
enclosing instance will not be injected, etc.

Issue: SPR-14150

This commit adds Smile and CBOR Jackson HttpMessageConverters
and make it possible to create Smile and CBOR ObjectMapper via
Jackson2ObjectMapperBuilder, which now allows to specify any
custom JsonFactory.

Like with JSON and XML Jackson support, the relevant
HttpMessageConverters are automaticially configurered by
Spring MVC WebMvcConfigurationSupport if jackson-dataformat-smile
or jackson-dataformat-cbor dependencies are found in the classpath.

Issue: SPR-14435

This commit upgrades the SonarQube plugin so that it is compatible with
Gradle 3.

Issue: SPR-14569

This commit also sets the test source encoding to UTF-8.

Issue: SPR-14547

* reactor-core 3.0.1.BUILD-SNAPSHOT
* reactor-netty 0.6.0.BUILD-SNAPSHOT

This commit ensures that JUnit XML reports are generated in the old
Gradle 2.x location for all tests in the spring-test module.

Issue: SPR-14569

Issue: SPR-14569

Since the upgrade to Gradle 3, our Bamboo build is failing because it
can't find test reports "at the usual location".

This commit restores the location that Gradle 2 was using until we
upgrade to a version of Bamboo that supports it.

Issue: SPR-14569

Previously the IDE (STS) was resolving a different reactor-core
version (3.0.0.BUILD-SNAPSHOT) than the build (3.0.0.RELEASE). This
discrepancy was due to the fact that reactor-netty now brings in
reactor-core 3.0.0.RELEASE. Gradle's version conflict resolution is to use
the latest version. However, the optional dependency on reactor-core
3.0.0.BUILD-SNAPSHOT was making the build path of the IDE use the SNAPSHOT.

This fix leverages a resolutionStrategy to ensure a consistent version of
reactor-core is used throughout the entire project. It also bumps up the
reactor-core version to 3.0.0.RELEASE to be consistent with reactor-netty.
Care is taken to only change 3.x vesion since 2.x is still used within
the codebase.

Issue: SPR-14569

Issue: SPR-14328

Issue: SPR-13344

Issue: SPR-13344

This commit also drops the now-unused CUSTOM_COMPILATION test group and the outdated JavaVersion class.

Issue: SPR-10423

Issue: SPR-11569

Issue: SPR-13575