impl(pubsub): pipe publish timeout to concurrent batch actor

[suzmue]

Extract the total timeout duration from the configured retry policy in BasePublisher and forward it through PublisherPartialBuilder and Dispatcher to ConcurrentBatchActor in preparation for publish request hedging. Calculating it this way means we may be off from the actual total_timeout by a small amount (the time between creating the state and querying total_timeout).

This is used by hedging to make sure that the timeout for a hedged request does not exceed the total timeout of the original request.

For #6776

[gemini-code-assist]

Code Review

This pull request introduces a total_timeout configuration of type Option<std::time::Duration> to the Pub/Sub publisher. It extracts the remaining time from the builder's retry policy during BasePublisher initialization and propagates this timeout through the PublisherPartialBuilder, Dispatcher, and ConcurrentBatchActor. Additionally, unit tests are added to verify the default, custom, and attempt-limit-only timeout behaviors. There are no review comments to address, and the changes conform to the repository's guidelines.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.17%. Comparing base (08fb84a) to head (f61c93f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6830      +/-   ##
==========================================
- Coverage   97.17%   97.17%   -0.01%     
==========================================
  Files         328      328              
  Lines      109546   109621      +75     
==========================================
+ Hits       106449   106521      +72     
- Misses       3097     3100       +3     

☔ View full report in Codecov by Harness.
📢 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.

[suzmue]

I think we will want to include the whole retry policy, it turns out we want to resolve responses with non-transient errors, so we want the policy to find out which ones are considered non-transient.