fix: close IO resources left open on abrupt or failing paths

[pjfanning]

Motivation

An audit of src/main for resource leaks turned up three places that open an IO resource and leave it open on at least one reachable path:

• ResolvConfParser.parseFile never closes the Stream returned by Files.lines, so the fd on /etc/resolv.conf stays open until GC. This is the only use of Files.lines in the tree.
• InputStreamSource.postStop fails the materialized value without closing the user-supplied InputStream. Every handler path closes it, but abrupt termination (materializer or actor system shutdown) skips the handlers, so the stream leaks. The sibling stages FileSource and OutputStreamGraphStage already close in postStop, so this one was the odd one out.
• ArteryAeronUdpTransport.autoSelectPort leaks the DatagramChannel when bind throws.

Modification

Close the Files.lines stream in a finally. parseLines consumes the iterator eagerly, so an eager close is safe.

Close the input stream in InputStreamSource.postStop before failing the promise. The close is inlined rather than delegated to closeInputStream, because that helper routes failures through failStage, which is pointless on an already torn-down stage. A close failure is logged at debug and the promise still fails with AbruptStageTerminationException.

Wrap the bind in autoSelectPort in try/finally.

All three are method-body changes with no signature change.

Result

None of the three paths leaks a file descriptor.

Tests

• sbt "stream-tests/testOnly org.apache.pekko.stream.io.InputStreamSourceSpec" — 9 succeeded, 0 failed. The new case "close the input stream on actor materializer shutdown" fails without the InputStreamSource change (8 succeeded, 1 failed) and passes with it.
• sbt "actor/compile" "stream/compile" "remote/compile" — success
• sbt "actor/mimaReportBinaryIssues" "stream/mimaReportBinaryIssues" "remote/mimaReportBinaryIssues" — success
• Native scalafmt run on the four changed files.
• No test for the ResolvConfParser and autoSelectPort fixes: neither changes observable behaviour, and asserting that an fd was released is not possible portably from Scala. Happy to add a Linux-guarded fd-count assertion if reviewers want one.

References

None - found by a resource-leak audit of src/main

[Philippus]

Maybe use scala.util.Using?

    scala.util.Using(Files.lines(file.toPath)) { lines =>
      parseLines(lines.iterator().asScala)
    }

[pjfanning]

The current code base prefers Java try with resources probably because Scala Using is not supported directly by Scala 2.12. If we want to start using Scala Using, I think we should have a general PR to do that across existing call sites. Apparently, it is pretty efficient and shouldn't be significantly different performance wise to try with resources.

[Philippus]

can also be used here:

  Using.resource(DatagramChannel.open().socket()) { socket =>
    socket.bind(new InetSocketAddress(hostname, 0))
    socket.getLocalPort
  }