Fix/spark 58751 listener shutdown

[nahtonaj]

What changes were proposed in this pull request?

This pull request handles state server shutdown while the listener is still waiting for the Python worker to connect.

The patch makes the following changes:

1. Reorders TransformWithStateInPySparkPythonRunner.stop() so that it interrupts the state server listener thread before closing the server socket channel. This matches the existing executor-side cleanup ordering.
2. Handles expected interruption and channel-closure exceptions thrown by ServerSocketChannel.accept() before the Python worker connects.
3. Preserves the listener thread's interrupt status for interrupt-driven shutdown and transitions the stateful processor handle to CLOSED.
4. Treats ClosedChannelException, including its AsynchronousCloseException subclass, as an expected shutdown path without incorrectly setting the interrupt status.
5. Adds regression coverage for the Java NIO exception hierarchy and interrupt semantics.
6. Adds real loopback ServerSocketChannel tests for both interruption before entering accept() and interruption while the listener is blocked inside accept(). The tests verify bounded listener termination, no escaped exception, channel closure, the CLOSED handle state, and no protocol output.

No public APIs or configuration options are added or changed.

Why are the changes needed?

When a TransformWithState in PySpark runner is stopped before the Python worker connects to its JVM state server, the listener can still be blocked in ServerSocketChannel.accept().

Previously, the driver-side cleanup closed the server socket channel before interrupting the listener thread. Closing the channel wakes the listener with an expected AsynchronousCloseException. Because the pre-connect path did not handle this exception, it escaped TransformWithStateInPySparkStateServer.run() and was wrapped as:

TransformWithStateInPySpark state server daemon thread exited unexpectedly (crashed)

This reports an orderly shutdown as an unexpected daemon-thread failure. The same listener implementation is used by the executor-side lifecycle, where interruption can produce ClosedByInterruptException.

The patch makes both expected shutdown paths explicit. It interrupts before closing, handles the relevant Java NIO exception hierarchy, restores the interrupt flag only for interrupt-driven shutdown, and transitions the processor handle to its terminal CLOSED state.

Does this PR introduce any user-facing change?

Yes.

Previously, stopping a TransformWithState in PySpark query before its Python worker connected could report the expected state server listener shutdown as an unexpected daemon-thread crash.

After this change, the state server listener terminates cleanly during this shutdown window. Expected interruption or channel-closure exceptions no longer surface as a spurious SparkException.

This is a bug fix relative to released Spark versions as well as the behavior on the current master branch. It does not change the TransformWithState API or successful query execution behavior.

How was this patch tested?

Added tests to TransformWithStateInPySparkStateServerSuite covering:

1. InterruptedException, InterruptedIOException, and ClosedByInterruptException while waiting for the Python worker, including preservation of the listener thread's interrupt status.
2. AsynchronousCloseException and ClosedChannelException while waiting for the Python worker, including verification that the listener thread is not marked interrupted.
3. A real loopback ServerSocketChannel with the listener thread already interrupted before entering accept().
4. A real loopback ServerSocketChannel with the listener confirmed to be blocked inside accept() before applying the production-equivalent interrupt-then-close shutdown sequence.
5. Bounded listener termination, no escaped throwable, server channel closure, transition to StatefulProcessorHandleState.CLOSED, and no protocol output for the real-channel shutdown paths.

The following local static checks passed:

git diff --check
dev/lint-scala

dev/lint-scala completed both the Scalastyle and Scalafmt checks successfully.

The focused suite can be run with:

build/sbt -Phive -Phive-thriftserver \
  "sql/core/testOnly org.apache.spark.sql.execution.python.streaming.TransformWithStateInPySparkStateServerSuite"

The focused SBT suite could not be executed in the local development environment because Maven Central and the SBT repository hosts failed DNS resolution while retrieving the required SBT launcher and dependencies. The generated partial launcher file was removed from the worktree. The suite is expected to run in GitHub Actions, where the build dependencies are available.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: databricks-gpt-5-6-sol on KiroCrew 0.2.0-customapi.5