fix(Spanner): prevent unnecessary GCE metadata probing during client …

[cy-yun]

Fix: Prevent unnecessary GCE metadata probing during SpannerClient initialization**

When a SpannerClient is instantiated, it automatically calls configureMetrics(). Previously, this method unconditionally resolved the Google Compute Engine (GCE) location by calling $this->getLocation().

In non-GCE environments (such as local development environments, emulators, or external CI pipelines), this triggers an HTTP probe to the GCE metadata server (169.254.169.254) that ultimately times out. This timeout introduces a completely unnecessary ~1.5 second delay to every single client instantiation.

Because the Spanner system tests repeatedly instantiate the SpannerClient, this delay heavily impacted the overall test suite execution time.

Changes Made

• Moved the $location = $this->getLocation(); resolution below the early return for when built-in metrics are disabled (which is the default behavior).
• Added testSpannerClientInstantiatesWithoutDelayWhenMetricsDisabled() to assert that the SpannerClient instantiates in under 1.0 second when metrics are disabled, ensuring no future regressions re-introduce the metadata probe delay.

Impact

By completely bypassing the metadata server probe for the default use case, this instantly recovers 1.5 seconds per SpannerClient instantiation in non-GCP environments. This dramatically speeds up local system test runs like BackupTest.php and improves local developer velocity.

Issue

• [Spanner] GCE metadata probe adding unnecessary delay when instantiating client #9316

[Hectorhammett]

This looks GTM but for some reason the Emulator System Tests are failing, I don't think this is related though 🤨

[cy-yun]

This looks GTM but for some reason the Emulator System Tests are failing, I don't think this is related though 🤨

You're right. It's not related. It's a flakey test that I'm addressing in #9329

The Spanner Emulator occasionally drops connections and triggers our automatic retry logic after it has already committed a row, causing the retry attempt to crash. I'll be swapping those tests to use idempotent insertOrUpdate() calls to fix the flakiness.