fix(o11y): use multi_thread for grpc test

[haphungw]

Use current_thread with delayed tokio::time::pause() for grpc_client_request_success to avoid flakiness and deadlocks.

I made a mistake previously when applying #[tokio::test(flavor = "current_thread", start_paused = true)] to this test. That caused a deadlock because the background gRPC server was started in a paused runtime and could not make progress before the client blocked.

The test originally used flavor = "multi_thread", which avoided the deadlock but left the test vulnerable to timing-sensitive flakiness (as noted by @coryan).

To fix both issues, I have:

1. Kept the default current_thread runtime.
2. Started the background gRPC server before pausing time.
3. Called tokio::time::pause(); after the server is ready and before the client request.

This ensures the test executes deterministically and fast without flakiness or deadlocks. We verified this by running 1,000 iterations without failure.

This surfaces in #5292 when the unstable_tracing guards are removed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.78%. Comparing base (7cbbd7d) to head (910df22).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5308   +/-   ##
=======================================
  Coverage   97.77%   97.78%           
=======================================
  Files         220      220           
  Lines       45765    45766    +1     
=======================================
+ Hits        44749    44750    +1     
  Misses       1016     1016           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coryan]

I fear this will flake as-is. I may be wrong, I am easy to convince (ha ha).

[coryan]

I think this will work, but maybe you can run the test a few times (say 1,000) to see if it flakes? You can use cargo nextest with some flags to run those 1,000 iterations with multiple parallel jobs so they finish quickly.

[haphungw]

I ran both flavor = "multi_thread" and tokio::time::pause(); with nextest, and multi_thread really just took to long that I did not bother finishing it.
The tokio::time::pause(); approach passed!

RUSTFLAGS="--cfg google_cloud_unstable_tracing" \
cargo nextest run \
  -p google-cloud-gax-internal \
  -E "test(observability::client_signals::tests::grpc_client_request_success)" \
  --count 1000 \
  --no-fail-fast \
  --success-output immediate-final