feat(auth): enrich invoke-level telemetry with transport detail

[westarle]

This PR has auth code fill in TelemetryTransportData in order to send details from the transport back up to higher layers. See googleapis/gax-go#496. This in turn allows code in those higher layers to report telemetry information for the last request that is only known by the transport layer.

Changes Made

• Logical Hostname Extraction: Updated extraction logic to parse logical hostnames and ports directly from req.URL (HTTP) and cc.Target() (gRPC) prior to invoking the transport
  layer.
• Implicit Port Fallback: Added scheme-based port fallbacks (80 for HTTP, 443 for HTTPS) when handling URLs with implicit ports.

[gemini-code-assist]

Code Review

This pull request enhances OpenTelemetry integration by adding metrics support for both gRPC and HTTP transports. For gRPC, a new unary client interceptor is introduced to extract server address and port from the target and populate gax.TransportTelemetryData, utilizing a new extractHostPort helper function. For HTTP, the otelAttributeTransport is updated to similarly extract server address, port, and response status code. New unit tests cover these telemetry functionalities and the extractHostPort helper. Review feedback indicates an improvement opportunity in extractHostPort's error handling when the port is invalid, suggesting it should return the parsed host instead of the full target string, along with a corresponding test case update.

[cpriti-os]

@westarle Not supporting Streaming is intended?

[westarle]

for now, yes.

[cpriti-os]

Can this loop be replaced with strings.TrimLeft(target, "/")

[westarle]

done thank you!

[quartzmo]

Can we use net/url.Parse here to parse and separate scheme, authority, and path more reliably?

If a target is dns://8.8.8.8/lb.example.com:443, this manual parsing might inadvertently extract 8.8.8.8/lb.example.com as the address, leaking internal DNS resolver details into public telemetry. It's kind of a contrived example tbh, but still...

[westarle]

I liked the idea of using net/url.Parse but what I found is that it behaves badly on endpoints that aren't well formatted (like it treats bare "googleapis.com/xyz" as the scheme and explodes on eg. "[::1]:443"

It is a great catch on dns://... ; I fixed it.

[quartzmo]

urlTemplate is guaranteed to be low-cardinality here, right? (Just checking...)

[westarle]

yes template needs to be low-cardinality like "/{name=projects/*/things/*}"

[quartzmo]

The *TransportTelemetryData pointer usage here and in the HTTP equivalent is not completely thread-safe.

Assuming this code is called via gax.Invoke (which scopes context per call using InjectTransportTelemetry), this is safe. However, if a user uses the gRPC or HTTP wrapper directly for requests in parallel while sharing a base context, it could trigger a data race.

Typical practice (outside of gax.Invoke) is often to reuse a base context (e.g., context.Background()) across multiple concurrent requests, thus with this code possibly writing to the shared data.SetServerAddress at virtually the same time. This risks overwriting request-specific values when the hosts differ. Even worse, concurrent writes to a non-thread-safe struct field can trigger the race detector.

While I don't think that we absolutely need to fix this for usage via gax.Invoke, here's the possible solution:

// 1. Pull the pointer
orig := gax.ExtractTransportTelemetry(req.Context())

// 2. Clone it (Shallow copy is fine for primitive fields)
var clone gax.TransportTelemetryData
if orig != nil {
    clone = *orig 
}

// 3. Set host for THIS request only
clone.SetServerAddress(req.URL.Hostname())

// 4. Scope it to THIS request's context
req = req.WithContext(gax.InjectTransportTelemetry(req.Context(), &clone))

[westarle]

I like the solution, but it breaks protocol with how invoke works today (today we allocate the struct in Invoke to avoid an allocation in the RPC path.)

I think you're saying that to experience the breakage a customer would have to

1. grab a raw Clients
2. inject a TransportTelemetryData into the context used for those clients
3. make parallel requests on the client

Maybe I can put a comment on TransportTelemetryData to say it's only for requests managed by Invoke?