RFR: JDK-6956385: URLConnection.getLastModified() leaks file handles for jar:file and file: URLs [v2]

[Jesse Glick]

> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/…something.jar!/…` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
> 
> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
> 
> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
> 
> 
> ./build/…-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
> 
> 
> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
> 
> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
> 
> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

Jesse Glick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Encapsulate logic as `FileURLConnection.closeInputStream` as suggested by @dfuch https://github.com/openjdk/jdk/pull/12871#discussion_r1198859517
 - Merge branch 'master' of https://github.com/openjdk/jdk into FileURLConnectionLeak-JDK-6956385
 - Simplified `instanceof` form
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - 6956385: `JarURLConnection` may fail to close its underlying `FileURLConnection`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12871/files
  - new: https://git.openjdk.org/jdk/pull/12871/files/d909a290..37b042c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=00-01

  Stats: 656633 lines in 6912 files changed: 510801 ins; 89679 del; 56153 mod
  Patch: https://git.openjdk.org/jdk/pull/12871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12871/head:pull/12871

PR: https://git.openjdk.org/jdk/pull/12871