SNOW-3643369: Always set explicit GCS credentials to prevent ADC probe in SPCS

[sfc-gh-dheyman]

Summary

• Always set explicit credentials on StorageOptions.Builder when GCS_ACCESS_TOKEN is present, removing the conditional guard on areDisabledGcsDefaultCredentials(). This prevents the GCS SDK from triggering an Application Default Credentials (ADC) lookup that probes metadata.google.internal — which is unreachable inside SPCS pods, causing an opaque invalid_gcs_credentials failure.
• Improve error handling in setupGCSClient: chain the original exception as the cause of IllegalArgumentException and log it at debug level, so the root cause (e.g., UnknownHostException) is visible in diagnostics instead of being silently swallowed.
• Let SnowflakeSQLException propagate directly from setupGCSClient instead of wrapping it in IllegalArgumentException, matching the method's declared signature.

Context

SPCS pods on GCP cannot reach metadata.google.internal (DNS fails). When the JDBC driver initializes a GCS storage client for PUT operations, the GCS SDK's ADC probe fails, and the broad catch (Exception) in setupGCSClient swallows the real error. This has been observed across multiple GCP deployments (gcpqa1, gcpuseast4). The fix ensures the ADC probe is never attempted when an access token is already available, and surfaces the root cause when initialization does fail.

Test plan

• Verified that setCredentials() is inside the if (accessToken != null) block, so null safety is guaranteed.
• Confirmed no callers specifically catch IllegalArgumentException — all use generic Exception catch, so the added exception chaining is backward-compatible.
• Confirmed GCSAccessStrategyAwsSdk (the virtual-URL path) already uses AnonymousCredentialsProvider and is not affected.
• Formatter (fmt-maven-plugin:format) and checkstyle (-P check-style) both pass cleanly.

Made with Cursor

[sfc-gh-merbel]

Please add more tests here

[sfc-gh-merbel]

Please take a look on failing tests.