feat(storage): multi-stream support in AsyncMultiRangeDownloader - #18537

… regeneration

…em tests (#18980)

## Summary

Adds Rapid system tests for the opt-in zero-copy
`BidiReadObjectResponse` parser
(`GCS_PYTHON_CLIENT_ZERO_COPY_BIDI_READ=1`) from #18627, as requested in
its review:

- `test_mrd_zero_copy_bidi_read`, a new test for behavior specific to
the parser: chunk types, buffer destinations and short reads.
- Every other test in `tests/system/test_rapid.py` that calls
`download_ranges` now runs with the parser off and on, and with
`accepts_memoryview` set to `False` and `True`.

They run with the existing Rapid system tests (and in manual RCU runs);
no CI changes.

## `test_mrd_zero_copy_bidi_read`

The test writes one 5 MiB appendable object, finalizes it, and reads it
back over a single `AsyncMultiRangeDownloader` stream with the parser
enabled:

- The stream uses the zero-copy `BidiReadObject` RPC, and the downloader
still gets the object size from the open response.
- A full-object read into a default `write()` destination receives only
`bytes` chunks.
- With `download_ranges(..., accepts_memoryview=True)`, chunks are
`memoryview`s when the installed `google-crc32c` accepts `memoryview`
and `bytes` otherwise (for example `google-crc32c` 1.9.0). The chunks
kept after the call still match the object data.
- One `download_ranges` call fills a `bytearray` and a writable
`memoryview` slice of a larger buffer, 2.5 MiB each. Guard bytes around
the slice catch out-of-range writes, and both buffers are cleared
afterwards, which fails if the SDK kept a view of either one.
- A read clamped at EOF into a buffer raises `BufferError` and leaves
the stream open. The buffer is cleared while the exception is still
held, which checks that the SDK released its view itself, and the next
read on the same downloader succeeds.

## Existing read tests

Two new fixtures: `zero_copy_bidi_read` sets
`GCS_PYTHON_CLIENT_ZERO_COPY_BIDI_READ` to `0` or `1` through
`monkeypatch`, so nothing leaks into later tests on the shared
session-scoped gRPC client, and `accepts_memoryview` is passed to every
`download_ranges` call. The 14 tests that call `download_ranges` take
both, on top of their `multi_stream_config` parameter from #18537, so
each runs in eight combinations: those tests go from 62 to 248 cases and
the file from 73 to 260. `test_mrd_zero_copy_bidi_read` keeps its own
settings. In the `python-sdk-zb-system-test` check, pytest takes 156 s
instead of 47 s on `main` (252 passed; the 8 skipped cases are the
read-handle test, which was already skipped).

## Testing

```
cd packages/google-cloud-storage
ruff check --select I tests/system/test_rapid.py
ruff format --check --target-version=py310 tests/system/test_rapid.py
flake8 tests/system/test_rapid.py
```

I ran the new test locally against an in-process `grpc.aio` server
implementing `BidiWriteObject` and `BidiReadObject` (responses of at
most 2 MiB, with and without an empty final response on a 2 MiB
boundary), once with `google-crc32c` 1.9.0 and once with a
`google-crc32c` build from `main` that accepts `memoryview`. Against the
same server I ran the 10 parametrized tests it can serve in all their
combinations, including both `multi_stream_config` values, checking that
each stream used the expected parser and each call passed the expected
`accepts_memoryview`; the cross-region, write-handle and
append-to-existing-object tests need a real bucket, and the read-handle
test is skipped. The `python-sdk-zb-system-test` check runs everything
against a real Rapid bucket.

---------

Co-authored-by: Anthonios Partheniou <partheniou@google.com>