chore(spanner): vendor grpc-gcp sources into google-cloud-spanner

[rahul2393]

Summary

This change vendors the grpc-gcp library directly into google-cloud-spanner so local grpc-gcp changes can be used in java-spanner without publishing a Maven snapshot first.

What changed

• copied grpc-gcp main sources into google-cloud-spanner
• copied required generated sources:
  • protobuf-generated com.google.cloud.grpc.proto.*
  • generated AutoValue_OpenTelemetryMetricsResource
• copied grpc-gcp unit tests and test resources into google-cloud-spanner
• skipped the upstream integration tests that depend on external Spanner/Bigtable setup
• removed the external com.google.cloud:grpc-gcp dependency from google-cloud-spanner
• added the remaining compile-time annotation dependency needed by the vendored sources
• removed the obsolete third-party/grpc-gcp staging README
• replaced the hardcoded 1.9.3-SNAPSHOT version string with a derived local implementation version

Why

Today, making grpc-gcp changes available to java-spanner requires:

1. releasing grpc-gcp
2. updating dependencies in sdk-platform-java
3. then consuming the updated artifact from java-spanner

That slows down iteration. Vendoring the library into google-cloud-spanner makes local development and testing of grpc-gcp changes possible in a single repo without relying on a published Maven artifact.

[gemini-code-assist]

Code Review

This pull request introduces significant changes to the gRPC-GCP library, including the addition of GcpClientCall, GcpManagedChannel, GcpMultiEndpointChannel, and related configuration and utility classes to support advanced channel management, affinity, and multi-endpoint routing. It also updates the project dependencies in pom.xml. My feedback highlights concerns regarding the use of an unbounded thread pool for state notifications, which could lead to resource exhaustion, and suggests explicitly managing the version of the newly added auto-value-annotations dependency to ensure build reproducibility.

[gemini-code-assist]

Using Executors.newCachedThreadPool() for state notifications can lead to resource exhaustion under high load. Consider using a bounded thread pool or a shared executor service.

References

1. Use bounded thread pools to prevent resource exhaustion. ^(link)
2. For safety, use a bounded thread pool (e.g., ThreadPoolExecutor with a defined maximum size) instead of an unbounded one (e.g., Executors.newCachedThreadPool()), even if the current logic seems to limit concurrent tasks.

[suztomo]

It seems you're copying the code from grpc-gcp to google-cloud-spanner. I'm afraid this will cause many NoSuchMethodError or NoClassDefFoundError going forward. https://jlbp.dev/JLBP-5 "Do not include a class in more than one classpath entry"

The right way is create grpc-gcp module with the same group ID and artifact ID as before. Maven and Gradle ensure that only one version of grpc-gcp artifact exists in the class path.

[rahul2393]

@suztomo You're right. I switched this from vendoring classes into google-cloud-spanner to a local grpc-gcp module with the same com.google.cloud:grpc-gcp coordinates, and restored google-cloud-spanner to depend on that artifact. That avoids duplicate-classpath issues while still allowing local iteration.

[suztomo]

This line should be managed by Release Please.

I believe there's one in sdk-platform-java/java-shared-dependencies.

[suztomo]

Let me merge #12746 first to make a releasable source tree and avoid unexpected unknown problem due to grpc-gcp. (com.google.cloud:grpc-gcp:1.9.2 already exists in Maven Central)