feat(storage): implement internal pre-warmed stream dispatch and caching for BiDi reads

[kalragauri]

This PR lays the groundwork to support eager streaming for BiDi reads in the GCS async gRPC client. It multiplexes read ranges into the handshake packets and builds the internal object descriptor caching layer.

NOTE: This PR is restricted to internal updates. Public API changes will be introduced in a subsequent PR.

Key Changes

• Updates internal streaming factories to conditionally append read_ranges into standard metadata headers on the very first BidiReadObjectRequest.
• Missing offsets or limits natively fall back to 0. This delegates unbounded reads, tail reads, or standard range boundaries to the GCS backend.
• The pre-warmed stream cache is strictly bound to identical offsets and limits.

[gemini-code-assist]

Code Review

This pull request introduces support for an initial read range (pre-warmed cache range) in the asynchronous storage client, allowing the client to skip making a new request on a cache hit. The review feedback highlights a critical use-after-move bug in AsyncConnectionImpl::Open, fragile member initialization order in ObjectDescriptorImpl, and a style guide violation regarding default parameters in an internal namespace, which requires reordering the constructor parameters and updating its callers.

[codecov]

Codecov Report

❌ Patch coverage is 97.24138% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.27%. Comparing base (e493b2d) to head (e944f9d).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...le/cloud/storage/internal/async/connection_impl.cc	50.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #16259      +/-   ##
==========================================
- Coverage   92.27%   92.27%   -0.01%     
==========================================
  Files        2214     2214              
  Lines      206505   206629     +124     
==========================================
+ Hits       190556   190667     +111     
- Misses      15949    15962      +13     

☔ 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.

[v-pratap]

So in all the cases will there be only one read range or we can give multiple read ranges?

[kalragauri]

For now, we are only allowing a single range. This optimization targets the 2 round trip penalty of stream setup + read intent. Once the stream is open, subsequent ranges can be multiplexed onto the established stream asynchronously without blocking the initial application threads.

For advanced use cases that require scattered multiplexed reads, ObjectDescriptorImpl already supports assigning multiple concurrent read_ids downstream once the session is opened:

google-cloud-cpp/google/cloud/storage/internal/async/object_descriptor_impl.cc

Lines 206 to 211 in 40d3ab0

	auto const id = ++read_id_generator_;
	it->active_ranges.emplace(id, range);
	auto& read_range = *it->stream->next_request.add_read_ranges();
	read_range.set_read_id(id);
	read_range.set_read_offset(p.start);
	read_range.set_read_length(p.length);

[v-pratap]

Yes, I understand that we have feature for sending multiple read requests later, but I think in a request we can send 100 read ranges and we are adding this feature to make our api faster. I just want to know whether sending multiple request with Open would make it more faster or sending one read range would be enough to warm up the stream?