[SPARK-58264][CONNECT][TESTS] Use OS-assigned ports in Connect server tests

[Ma77Ball]

What changes were proposed in this pull request?

Bind the Spark Connect server test harness to port 0 so the OS assigns a free port, instead of guessing CONNECT_GRPC_BINDING_PORT + Random.nextInt(1000):

• SparkConnectServerTest starts the service on port 0 via a new startService helper and reads the real bound port from SparkConnectService.localPort into serverPort.
• SparkConnectServiceKeepAliveSuite restarts via a new restartService helper that rebinds to port 0 rather than reusing a fixed port.
• RemoteSparkSession launches the server process with binding port 0 and passes a spark.connect.test.portFile. It reads the real bound port back from that file instead of pre-reserving one, which removes a time-of-check/time-of-use (TOCTOU) window where a reserved-then-closed port could be taken before the server binds it.
• SimpleSparkConnectService writes the actual bound port to the configured portFile.

Why are the changes needed?

The guessed fixed port races other processes and parallel test JVMs for a specific port, causing intermittent BindException. Letting the OS pick a free port removes that race, and also removes the stop/start-same-port window since the OS never hands back a port that is still bound or closing. For the client harness, having the server bind port 0 itself and report the real port avoids pre-reserving a port (a TOCTOU race).

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Existing Connect server and client-jvm suites. connect and connect-client-jvm compile; scalafmt, scalastyle, and ASCII/line-length lint pass.

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

Generated-by: Claude Opus 4.8

[uros-b]

cc @sarutak @Ma77Ball regarding #57560 (review).

[Ma77Ball]

@uros-b either PR should resolve this flake. The main difference is that binding to port 0 instead of a fixed guessed port also removes the potential collision with other processes or parallel JVMs more of a latent race than the observed failure but it lets us drop fixed ports from the harness entirely. It also avoids the probe-then-rebind TOCTOU (time-of-check to time-of-use) window that the fixed-port approach still leaves open.