Ensure that the source jar entry is closed before reading
certificates and code signers from the entry.

gh-19041

Closes gh-23181

Closes gh-23190

Update `JarFileEntries` so that the interface is obtained rather than
the concrete implementation. This allows `JarEntry` values to be used
without causing a ClassCastException.

Closes gh-19041

Closes gh-23269

Closes gh-23278

Closes gh-23277

Closes gh-23276

Closes gh-23275

Closes gh-23274

Closes gh-23273

Closes gh-23272

Closes gh-23271

Closes gh-23270

Closes gh-23268

Closes gh-23267

Closes gh-23266

* pr/19041:
  Polish 'Fix signed jar performance issues'
  Fix signed jar performance issues
  Ignore Visual Studio Code Files

Closes gh-19041

Update the performance improvements to push certificate loading
and storage into the `JarFileEntries` class. This allows us to
keep certificates without needing to cache all entry data. We
now also keep certificates and code signers in a dedicated class
which is set whenever the full jar stream as been read, even if
the contained values are `null`. The logic that assumes META-INF
entries are not signed has been removed in favor of delegating to
the streamed entry results.

See gh-19041

Update Spring Boot nested JarFile support to improve the performance of
signed jars. Prior to this commit, `certificates` and `codeSigners`
were read by streaming the entire jar whenever the existing values
were `null`. Unfortunately, the contract for `getCertificates` and
get `getCodeSigners` states that `null` is a valid return value. This
meant that full jar streaming would occur whenever either method was
called on an entry that had no result. The problem was further
exacerbated by the fact that entries might not be cached.

See gh-19041

See gh-19041

See gh-23185

See gh-23194

See gh-23190

See gh-23181

Closes gh-23113

Closes gh-23102

* pr/23071:
  Disallow Apache Commons Lang & Lang3 imports

Closes gh-23071

See gh-23071

Closes gh-23055

Closes gh-22755

Closes gh-22717

* pr/22704:
  Fix broken links to Micrometer registry docs

Closes gh-22704

See gh-22704

Closes gh-22659

The overhead of build scans seems to have brought us right to the limit
of the Maven JVM's heap. As a result, builds are occasionally failing
as the heap's been exhausted.

This commit increases the JVM's max heap.

Closes gh-22649

* gh-22614:
  Upgrade to Gradle Enterperise Maven Extension 1.6.0

Closes gh-22614

See gh-22614