[qianlan717]

What changes were proposed in this pull request?

This PR adds the public session configuration
spark.connect.session.serverSideMavenResolution.enabled, defaulting to false.

The Spark Connect JVM client sends an eligible ivy:// dependency to the server only when the
server advertises support, the session configuration is enabled, and the URI does not specify
repositories through repos. Otherwise, the dependency is resolved by the client. The server
capability remains cached support metadata, while the routing preference is read for every
addArtifact or addArtifacts call so it can change at runtime.

For client-resolved Ivy URIs, the JVM client reads spark.jars.ivySettings through the Config RPC,
including configuration substitution. It uses the setting only when it resolves to a readable
regular local file, loads that Ivy settings file during resolution, and uploads the resolved jars
to the server. Missing, unreadable, or non-local settings retain the built-in Ivy defaults.

The routing configuration is a JVM-client preference, not a server-side enforcement control. The
server continues to accept Maven dependency requests sent directly by protocol clients.

This is split from #59977, which is limited to reading Maven settings from the owning SparkSession
for driver/server resolution. The two PRs have no code dependency and can be reviewed separately.

Why are the changes needed?

JIRA: https://issues.apache.org/jira/browse/SPARK-60773

Server capability advertisement describes whether server-side Maven resolution is supported, but
it should not automatically select that path for every session. Separating cached capability
detection from the mutable session preference keeps client-side resolution as the default and lets
a session opt in when server-side repository access is desired.

When resolution stays on the JVM client, it must honor a locally available
spark.jars.ivySettings; otherwise switching to the client can bypass the configured repository
settings and use only the built-in defaults.

Does this PR introduce any user-facing change?

Yes, relative to the unreleased master behavior. An eligible Spark Connect JVM ivy://
dependency is now resolved on the client by default instead of automatically using the server when
the server advertises support. A session can opt in with:

spark.conf.set(
  "spark.connect.session.serverSideMavenResolution.enabled",
  "true")

Client-side resolution now uses spark.jars.ivySettings when it names a locally readable file.
Dependencies with an explicit repos query parameter remain client-resolved. Spark Classic is
unaffected by the routing configuration.

How was this patch tested?

Added ArtifactSuite coverage for client and server routing, runtime configuration changes,
whitespace accepted by the Boolean configuration, locally readable Ivy settings with substitution
and URI escaping, single and batch artifact calls, explicit repositories, and missing server
capability.

Added SparkConnectConfigHandlerSuite coverage confirming that Config RPC reads return the
registered false default.

Ran:

build/sbt 'connect/Test/compile' \
  'connect-client-jvm/testOnly org.apache.spark.sql.connect.client.ArtifactSuite' \
  'connect/testOnly org.apache.spark.sql.connect.service.SparkConnectConfigHandlerSuite'

ArtifactSuite: 23 tests passed. SparkConnectConfigHandlerSuite: 19 tests passed.
git diff --check, changed-source line-length checks, and non-ASCII checks also passed.

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

Generated-by: OpenAI Codex (GPT-5)