Rework commit b726974b to avoid exposing setters that would permit anyone
to change Spring Boot's defaults. Also, since these are configurers of a
specific instance, they should be named accordingly.

Closes gh-5138

Fixup accidental error in previous commit.

Update a few of the samples to correct the packages used in tests and
to make use of the `@SpringBootApplication` annotation.

The Jolokia auto-configuration requires ServletWrappingController from
Spring MVC to be on the classpath. This commit updates the
auto-configuration to make it conditional on the presence of this
class.

Closes gh-5153

There's a long cycle when Spring Data REST, Data JPA and Actuator
are used in an app that retrieves its DataSource from JNDI. The cycle
is:

- WebMvcAutoConfiguration
- HttpMessageConverters
- MappingJackson2HttpMessageConverter (needs an ObjectMapper)
- SpringBootRepositoryRestMvcConfiguration
- ObjectMapper
- RepositoryResourceMappings (part of a custom Jackson module)
- Repositories
- EntityManagerFactory (Triggered by application's Spring Data JPA repository)
- HibernateJpaAutoConfiguration
- JndiDataSourceAutoConfiguration
- MBeanExporter (Used to prevent export of DataSource MBean that's already in JMX)
- EndpointMBeanExportAutoConfiguration
- ObjectMapper (Used to format JSON produced by the exported endpoints)

Spring Data Rest caused the ObjectMapper to depend on JPA. JPA depends
on the DataSource. JnidDataSourceAutoConfiguration depends on the
MBeanExporter. Actuator's MBeanExporter requires an ObjectMapper to
produce JSON strings.

This commit breaks the cycle by making JndiDataSourceAutoConfiguration
access the MBeanExporter lazily. Rather than using `@Lazy`. which does
not work with `@Autowired(required=false)`, the application context
is injected and the MBeanExporter is retrieved manually when it is
needed.

Closes gh-4980

* gh-5190:
  Upgrade to Spring Integration 4.2.5.RELEASE

Closes gh-5190

Closes gh-5182

Closes gh-4149

Spring Boot supports the automatic configuration of an additional
HazelcastInstance if one already exists and an explicit property has been
set to use a different configuration for caching. So three cases are
supported really: no `HazelcastInstance` exists so we need to create one
anyway or an `HazelcastInstance` already exists; in that latter case, we
should either reuse it or create a new one.

Unfortunately, the conditions that checked those three use cases were
not ordered consistently and we could easily get in a situation where
both conditions were evaluated.

This commit makes sure that we  first check if an `HazelcastInstance`
exists and then (and only then) we create the missing `HazelcastInstance`
used for caching. The tests have also been improved to validate the
proper `HazelcastInstance` is used for caching.

Closes gh-5181

Closes gh-5160

Closes gh-5161

Conflicts:
	spring-boot-dependencies/pom.xml

Remove the reference to the spring-boot:test jar since it's not
published.

See gh-5184

Update the requestsWithDisallowedMethodsAreRejected test to use PATCH
rather than HEAD. The change is to allow support for Spring Framework
4.3 which will implicitly map HEAD requests to GET.

Pre-flight requests are also only for "non-simple" HTTP methods [1]
(i.e. anything but GET, HEAD, POST) so there is really no such a thing
as a pre-flight request for HEAD.

[1] https://www.w3.org/TR/cors/#resource-preflight-requests

Relocate the `org.springframework.boot.test` package from the
`spring-boot.jar` to `spring-boot-test.jar`.

Fixes gh-5184

Rework a few parts of the diagnostics support:

- Move code from SpringApplication to FailureAnalyzers
- Allow AbstractFailureAnalyzer to take generic cause type
- Move own analyzers into a new package and make package private

See gh-4907

Closes gh-5183

* gh-4823:
  Polish contribution
  Make TLS protocols and cipher suites configurable via the environemnt

Rename the new property to enabledProtocols to align more closely with
Undertow and Tomcat’s underlying configuration setting.

Closes gh-2109

Closes gh-4823

Closes gh-5161

This commit introduces a new failure analysis mechanism that can be
used to provide diagnostics to a user when their application fails
to start.

When application context refresh fails. FailureAnalyzer
implementations are loaded via spring.factories. The analyzers are
called in order, with the first non-null analysis of the failure
being used. The analysis is reported to the use by
FailureAnalysisReporters which are also loaded via spring.factories.

A single FailureAnalysisReporter is provided out of the box. It logs
an error message with details of the analysis, providing the user
with a description of the failure and, if available, some actions
that they may be able to take to resolve the problem without also
displaying a stack trace that is of little value.

Two analysers are provided initially. One for an embedded servlet
container port clash and another for BeanCurrentlyInCreationExceptions.
More analysers are planned (for UnsatisfiedDependencyException and for
NoUniqueBeanDefinitionException) once some updates have been made
to Spring Framework to make those failures more amenable to analysis.

Closes gh-4907

See gh-4897

Closes gh-4897

When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.

Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.

This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.

Closes gh-4897
Fixes gh-4868