Closes gh-6249

Closes gh-6315

Fixes gh-6312

Closes gh-6275

Closes gh-6276

Closes gh-6276

Closes gh-6274

Closes gh-6273

Closes gh-6271

Closes gh-6270

Closes gh-6269

Closes gh-6268

Closes gh-6267

Closes gh-6266

Closes gh-6265

Previously, Log4J2LoggingSystem used ResourceUtils.isFileURL(URL) to
check that the URL of the configuration was suitable for accessing as a
File. Unfortunately, this fails when the URL’s protocol is vfs or
vfsfile as both return true and then fail when the URL is subsequently
passed into ResourceUtils.getFile(URL).

This commit switches to checking that the URL’s protocol is file,
the only protocol that will allow getFile(URL) to succeed.

Closes gh-6246

Closes gh-6245

See gh-6249

* pr/6176:
  Polish "Use missing MongoClientOptions in MongoProperties"
  Use missing MongoClientOptions in MongoProperties

Closes gh-6176

See gh-6176

* pr/6203:
  Polish "Add condition on MongoClientFactoryBean"
  Add condition on MongoClientFactoryBean

Closes gh-6203

This commit makes sure that the condition that links a `MongoClient` to
the embedded mongo server kicks in only if `MongoClientFactoryBean` is
also on the classpath.

Previously, only a condition on the mongo driver existed, leading to
`ClassNotFoundException` if Spring Data MongoDB wasn't available.

See gh-6203

Previously, if a property name had successive capital letters, the
generated meta-data would clean it in such a way it is defined as a
regular word. For instance a `myFOO` property would be written as
`my-foo` in the meta-data.

It turns out this decision is wrong as the binder has no way to compute
back the name of the property and therefore `my-foo` wouldn't bind to
`setMyFOO` as it should.

This commit updates the meta-data name generation algorithm to properly
identify such cases: `myFOO` now translates to `my-f-o-o`. While the
generated name is a bit ugly, it now provides a consistent binding
experience.

Closes gh-5330

JarURLConnection is very performance sensitive. The change in 3772d9f9
meant that every JarURLConnection would create a FilePermission,
irrespective of whether it was actually used.

This commit updates JarURLConnection to create its FilePermission
lazily. When there is no security manager a permission will no longer
be created at all.

Closes gh-5411
See gh-6215

springloaded isn't required in any of the samples, yet some of them
make use of it without being a springloaded-specific sample. This
is creating the false impression that springloaded is necessary in
cases where it's not.

Closes gh-5524

When a custom management.port is used, the child context is configured
with an EmbeddedServletContainerFactory bean that has the same class
as the parent context’s EmbeddedServletContainerFactory bean. This
ensures that the child context uses the same type of embedded container
as its parent when there are multiple embedded containers on the
classpath. It also causes a failure when the custom
EmbeddedServletContainerFactory subclass cannot be instantiated, for
example because it’s an anonymous inner-class.

This commit improves the diagnostics so that we fail fast with an
information exception message when we detect that the embedded servlet
container factory bean’s class cannot be instantiated.

Closes gh-6193

See gh-5330

Closes gh-2893

* pr/6184:
  Fix relaxed binding of SI JMX config

Instead of using an expression for JMX-related properties, this commit
properly honors relaxed binding.

Closes gh-6184

Previously, if the `contextPath` of the application wasn't the root, the
HAL browser could not initialize since the `entryPoint` was referring to
an invalid location.

This commit makes sure to take the `contextPath` into account.

Closes gh-5814

Previously, SimpleInMemoryRepository used a ConcurrentReferenceHashMap
to store its locks. The type of map will discard its entries when the
JVM comes under GC pressure. With the code in its previous form, this
could lead to a NullPointerException when the following occurred:

1. putIfAbsent returned null indicating that a new entry has been added
   to the map
2. GC pressure caused the map to discard the new entry
3. get returned null as the entry has been discard

There are two problems with the existing code:

1. Its usage of a ConcurrentMap is incorrect. The correct usage is:
   a. Call get to see if the map already contains a lock
   b. If the lock is null, create a new one
   c. Call putIfAbsent to add the new lock
   d. If the return value is non-null, another thread has created the
      lock and it should be used. If the return value is null, use the
      new lock created in b.
2. Once the use of ConcurrentMap has been corrected, the fact that it is
   a ConcurrentReferenceHashMap means that different threads could
   access the same value using different locks. This would occur if one
   thread has retrieved a lock from the map and is using it, while GC
   causes the lock to be removed from the map. Another thread then
   attempts to get the lock and, as GC pressure has remove it, a new
   lock is created allowing concurrent access to the same value.

This commit updates the code to use the ConcurrentMap correctly and also
replaces the ConcurrentReferenceHashMap with a ConcurrentHashMap. This
means that the repository will now use slightly more memory but this is
outweighed by the benefits of thread-safe updates and no risk of an NPE.

Closes gh-6115

DevTools deliberately throws an uncaught exception on the main thread
as a safe way of causing it to stop processing. This exception is
caught and swallowed by an uncaught exception handler. Unfortunately,
this has the unwanted side-effect of causing the JVM to exit with 1
once all running threads are daemons.

Normally, this isn't a problem. Non-daemon threads, such as those
started by an embedded servlet container, will keep the JVM alive and
restarts of the application context will occur when the user makes to
their application. However, if the user adds DevTools to an
application that doesn't start any non-daemon threads, i.e. it starts,
runs, and then exits, it will exit with 1. This causes both
bootRun in Gradle and spring-boot:run in Maven to report that the
build has failed. While there's no benefit to using DevTools with an
application that behaves in this way, the side-effect of causing the
JVM to exit with 1 is unwanted.

This commit address the problem by updating the uncaught exception
handler to call System.exit(0) if the JVM is going to exit as a
result of the uncaught exception causing the main thread to die. In
other words, if the main thread was the only non-daemon thread, its
death as a result of the uncaught exception will now cause the JVM
to exit with 1 rather than 0. If there are other non-daemon threads
that will keep the JVM alive, the behaviour is unchanged.

Closes gh-5968