In an MVC web application, DelegatingWebMvcConfiguration provides the
ConversionService while also consuming WebMvcConfigurerAdapters that,
among other things, can configure HTTP message converters. Boot's
WebMvcConfigurerAdapter, WebMvcAutoConfigurationAdapter, consumes
the HttpMessageConverters bean and uses it to configure Spring MVC's
HTTP message converters. This can create a bean dependency cycle if
an HTTP message converter bean depends, directly or indirectly on
the ConversionService. An example of the cycle is:

┌─────┐
|  jsonComponentConversionServiceCycle.ThingDeserializer defined in …
↑     ↓
|  org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration$EnableWebMvcConfiguration
↑     ↓
|  org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter
↑     ↓
|  org.springframework.boot.autoconfigure.web.HttpMessageConvertersAutoConfiguration
↑     ↓
|  mappingJackson2HttpMessageConverter defined in class path resource [org/springframework/boot/autoconfigure/web/JacksonHttpMessageConvertersConfiguration$MappingJackson2HttpMessageConverterConfiguration.class]
↑     ↓
|  jacksonObjectMapper defined in class path resource [org/springframework/boot/autoconfigure/jackson/JacksonAutoConfiguration$JacksonObjectMapperConfiguration.class]
└─────┘

This commit breaks the cycle by making WebMvcAutoConfigurationAdapter
consume HttpMessageConverters lazily. This allows the adapter to be
created without triggered instantiation of every HTTP message
converter bean and all their dependencies. This allows it to be
injected into DelegatingWebMvcConfiguration without triggering an
attempt to retrieve the ConversionService.

Closes gh-9409

Closes gh-9084

Clarify the cache sample and in particular that Infinispan does not
bootstrap with a default configuration file. Hence the custom
`infinispan.xml` configuration is enabled by default if Infinispan is
available on the classpath.

See gh-9417

Closes gh-9423

Closes gh-9422

See gh-9425

Closes gh-9424

* gh-9259:
  Polish "Copy conversion service when performing environment conversion"
  Copy conversion service when performing environment conversion

Closes gh-9246

Previously, when a web environment was converted to a
StandardEnvironment, any customizations of the source environment's
ConversionService were lost.

This commit updates the logic that performs the conversion to copy
the source's ConversionService to the converted environment, thereby
ensuring that any customizations are retained.

Closes gh-9259
See gh-9246

See gh-9248

Closes gh-9248

Prior to this commit, custom `ProtocolResolvers` set on the
`ApplicationContext` were lost when Devtools is used as the customized
`ResourceLoader` did not copy any customization made to the default
resource loader.

This commit makes sure to copy any `ProtocolResolver` set on the context.

Closes gh-9331

Closes gh-9054

Closes gh-9360

Closes gh-9410

Closes gh-8927

Closes gh-9407
Closes gh-9135

Different versions of Docker produce different responses when building
and tagging an image. On CI, a response with a stream like
"Successfully built 185991ffe24a" followed by a response with a
stream like "Successfully tagged spring-boot-it/centos:6.9-a23bced6"
is received. By default, for the building of an image to be considered
successful, the Docker Java client requires the stream for the last
response item to contain "Successfully built". This means that, on the
CI server, it incorrectly believes that the building of the tagged
image has failed.

This commit uses a custom BuildImageResultCallback that doesn't
require the last response to be the one that has a stream containing
"Successfully built". Instead, it looks back through the error-free
responses (newest to oldest) looking for one with a stream containing
"Successfully built".

CentOS 5 was declared EOL in March 2017 and yum on longer works
out of the box. 6.9 is the latest release of CentOS 6. Tests for
CentOS 7 have not been added as it uses systemd rather than SysVinit.

Closes gh-9395

* pr/8595:
  Fix OptionalLiveReloadServer create bean

Closes gh-8595

Closes gh-9073

Closes gh-9387

Previously, BeanCurrentlyInCreationFailureAnalyzer would return
a FailureAnalysis for any BeanCurrentlyInCreationException even if
it could not determine where the cycle begins. This could lead to an
inaccurate diagram of the cycle being output.

This commit updates BeanCurrentlyInCreationFailureAnalyzer so that
it abandons its analysis and returns null if it is unable to determine
where the cycle begins.

Closes gh-8164