feat(lro): trace GetOperation query and poll sleep

[abhinavgautam01]

Fixes #5625

Summary

This change improves LRO (google.longrunning) polling observability when the crate is built with --cfg google_cloud_unstable_tracing and the poller is constructed with an LRO parent span.
It implements the remaining tracing work described in #5625:

• T3 — GetOperation span: Each status/query RPC is wrapped in a span named google.longrunning.Operations/GetOperation, matching the API surface users and backends already talk about.
• T5 — sleep span: Backoff sleep between polls is wrapped in its own child span (LRO Poll Sleep) so “waiting” time is separated from other polling work under the existing LRO Polling span.

Behavior notes

• Spans for the poll loop (LRO Wait, LRO Polling, sleep, and GetOperation) are only attached when an LRO parent span is provided; callers that do not opt in keep the previous, non-instrumented behavior.
• poll() now clones the operation name for the query closure and passes the original name into handle_poll. That keeps semantics correct in all builds and avoids moving the name twice.

Testing

• Unit tests capture span names with tracing-subscriber when google_cloud_unstable_tracing is enabled.
• Default builds (without the cfg) are covered by existing tests; cargo clippy / cargo test were run with and without the tracing cfg.

[gemini-code-assist]

Code Review

This pull request introduces tracing instrumentation for Long Running Operations (LRO) under the google_cloud_unstable_tracing feature flag. It adds span constants and instruments the poll and until_done methods to provide visibility into polling attempts and sleep intervals. A comprehensive test suite was added to verify span behavior. Feedback was provided regarding significant code duplication in the until_done method, where the polling loop is implemented twice for different configuration flags; a refactor was suggested to unify the logic and improve maintainability.

[coryan]

You are duplicating the work in 5621 and 5629.

[abhinavgautam01]

You are duplicating the work in 5621 and 5629.

Thanks @coryan that makes sense. 5621 touches the same aip151.rs naming (e.g. longrunning_span / gcp.longrunning.*), so I’ll rebase onto it once it lands and match that. 5629 is the T2 + generator side; my change is #5625 (T3/T5 only) in the poller. I’ll rebase again after 5629 if the LRO factory API changes. No intent to redo the 5629 work...or should i close this one..!?

[coryan]

Let's close this. I expect we will want to implement 5625 ourselves. If you are looking for something else to do after #5630, then maybe #1587 may be a good idea.

[abhinavgautam01]

Let's close this. I expect we will want to implement 5625 ourselves. If you are looking for something else to do after #5630, then maybe #1587 may be a good idea.

sure..I’d be happy to take a look at #1587 ..!