This commit reinstanties the isWeBClientPresent() check so that
WebTestClientContextCustomizer is only added if a web client is
available.

See gh-24152

Closes gh-24251

Closes gh-24250

* pr/24208:
  Polish "Reduce redis health indicator info command result size"
  Reduce redis health indicator info command result size

Closes gh-24208

See gh-24208

See gh-24208

Closes gh-24234

* pr/24230:
  Polish "Allow to exclude an empty set of ErrorAttributes"
  Allow to exclude an empty set of ErrorAttributes

Closes gh-24230

See gh-24230

See gh-24230

Closes gh-24224

Closes gh-24137

Closes gh-24223

Closes gh-24222

Fixes gh-24123

Closes gh-24220

Closes gh-24219

* gh-24095:
  Polish "Ensure that MeterRegistry bean is defined before SI looks for it"
  Ensure that MeterRegistry bean is defined before SI looks for it

Closes gh-24095

See gh-24095

Previously, it was possible for Spring Integration, including its
built-in Micrometer support, to be auto-configured before the
Micrometer auto-configuration had defined the MeterRegistry bean. This
resulted in missing Spring Integration metrics.

Spring Integration is unusual in having its own built-in Micrometer
support that it configures itself. Rather than providing
auto-configuration for Integration's Micrometer support (Which isn't
needed), this commit introduces some auto-configuration that just
affects the ordering of the auto-configuration classes. This ordering
ensures that the MeterRegistry bean has been defined by Spring
Integration is auto-configured. This ensures that the MeterRegistry
bean is known to the BeanFactory when Spring Integration goes looking
for it.

See gh-24095

Web MVC and WebFlux look up by name the Locale(Context)Resolver beans
that they use. Previously, the auto-configured resolvers for MVC and
WebFlux would back off when any bean of the required type was defined,
irrespective of its name. If the name of the user's bean didn't match
the name used by MVC and WebFlux to find the custom resolver, the
custom resolver would be ignored and MVC and WebFlux would use their
defaults. There was no indication of this happening in the condition
evaluation report as all it would show is that the auto-configured
resolver had backed off in favour of the custom resolver. It wouldn't
show anything to explain why the custom resolver had not been used.

This commit updates the auto-configured resolvers to be conditional
on a missing bean of the name required by MVC and WebFlux. If the
user then defines a custom resolver with a different name, the
condition evaluation report will show that the auto-configured
resolver remained as the bean name didn't match.

Fixes gh-24209

Fixes gh-24158

Closes gh-24203

Closes gh-24200

Wrapper's isWrapperFor and unwrap methods both take a Class<?> target
but document that the target should be an interface. Prior to this
change, we were calling isWrapperFor with any Class<?> irrespective of
whether or not it was an interface. When using Oracle UCP each call
to isWrapperFor with an interface results in an exception stack trace
being logged.

This commit upates DataSourceUnwrapper to adhere to Wrapper's contract
by only calling isWrapperFor and unwrap with interfaces.

Fixes gh-24154

Closes gh-24199

Closes gh-24198

Closes gh-24197

Closes gh-24196

Closes gh-24195

Closes gh-23558

Closes gh-24194

Closes gh-24193

* pr/24147:
  Polish "Avoid unnecessary pattern compilation in WebFluxTags"
  Avoid unnecessary pattern compilation in WebFluxTags

Closes gh-24147

See gh-24147

See gh-24147

Update `SpringBootConfigurationFactory` so that it no longer attempts
to get a `LoggingSystem`.

The recent `LoggingSystem` update means makes use of the
`SpringFactoriesLoader` class to load candidate logging systems.
Unfortunately, the `SpringFactoriesLoader` class creates a `Logger`
which (when using Log4J2) causes `SpringBootConfigurationFactory` to
run. Calling `LoggingSystem.get` from `SpringBootConfigurationFactory`
results in a recursive call to `SpringFactoriesLoader` which hasn't
yet been fully initialized. We then see an NPE caused by a `null`
`cache`.

This update removes the call to `LoggingSystem.get` with the assumption
that it would never return `null` anyway.

Fixes gh-24163

Closes gh-24188

Closes gh-24187

Closes gh-24145