feat(spanner): add setMetricsProjectId to fix metrics export

[RRap0so]

Fixes #13240

Problem

On GKE with shared VPC, SpannerOptions.getProjectId() defaults to the host project via the metadata server. While DatabaseId correctly routes database operations to the application project, the client-side metrics exporter uses getProjectId() — causing createServiceTimeSeries to target the wrong project and fail with permission errors.

Changes

• Add setMetricsProjectId(String) to SpannerOptions.Builder
• Add resolveMetricsProjectId() that prefers explicit value, falls back to getProjectId()
• Update 3 metrics export call sites to use resolveMetricsProjectId()
• Log WARNING in getDatabaseClient() when DatabaseId project differs from metrics project

Usage

SpannerOptions options = SpannerOptions.newBuilder()
    .setMetricsProjectId("my-app-project")
    .build();

When not set, behavior is unchanged (uses getProjectId()).

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces the ability to explicitly configure a project ID for client-side metrics export via SpannerOptions, addressing potential permission issues in environments like GKE with shared VPCs. The changes include adding a metricsProjectId field to the SpannerOptions builder and updating metrics initialization to use this resolved project ID. Feedback suggests moving the project mismatch warning in SpannerImpl to the client initialization block to avoid excessive logging on every getDatabaseClient call and ensuring that equals() and hashCode() in SpannerOptions are updated to include the new field.

[gemini-code-assist]

The warning for project ID mismatch is currently logged on every call to getDatabaseClient. Since this method is frequently called during normal operation, this can lead to excessive log spam and unnecessary performance overhead. It is recommended to move this check inside the conditional block where a new DatabaseClient is actually created (i.e., when !dbClients.containsKey(db)). This ensures the warning is logged at most once per DatabaseId for the lifetime of the Spanner instance.

[gemini-code-assist]

When adding a new configuration field like metricsProjectId to SpannerOptions, it is essential to update the equals() and hashCode() methods to include it. Failure to do so can cause issues when SpannerOptions instances are used as keys in caches or when comparing configurations for equality.