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.

[sakthivelmanii]

Can you address these comments and rebase it with the latest main?

[RRap0so]

Hey @sakthivelmanii, thank you for the review. Simplified it a bit and removed the log line probably not necessary.

[rahul2393]

@RRap0so thanks for raising the PR, can you check if this fix #13262 is sufficient to solve your issue? by exposing a public method it is possible to export built-in metric for a database to separate project(though we can log warning) which is not expected, and the fix I shared handled those cases without exposing an option.

[RRap0so]

@rahul2393 you folks will know best. If it's not intended for users to define a different Metrics Project ID then your PR should do it.

[rahul2393]

Ok, From spanner side we ideally would not like to expose that as public setter, let me try getting reviews on the PR, if it's not reviewed or I see concern from team, we will go ahead with the public setter