feat(bigtable): support materialized views in the data client

[axyjo]

Summary

Adds materialized view support to the Bigtable data client, alongside the existing Table and AuthorizedView surfaces:

• New MaterializedView / MaterializedViewAsync classes (subclasses of _DataApiTarget) and a client.get_materialized_view(instance_id, materialized_view_id) factory. Reads (read_rows*, sample_row_keys, row_exists) route requests via the materialized_view_name field.
• Materialized views are read-only in the Bigtable API — the mutation RPCs have no materialized_view_name field — so mutate_row, bulk_mutate_rows, check_and_mutate_row, read_modify_write_row, and mutations_batcher are overridden to raise NotImplementedError immediately instead of failing with an opaque proto error (or, for the batcher, failing later in a background flush).
• Since materialized views are instance-scoped and have no backing table, table identity (table_id/table_name) moves from the shared _DataApiTarget base class into the Table and AuthorizedView subclasses. Public constructor signatures are unchanged.
• Sync surfaces regenerated via nox -s generate_sync; docs pages added for both new classes.

Test plan

• Unit tests: new TestMaterializedView suites (async + generated sync) cover construction, routing metadata (name=<instance path> header), factory passthrough, context-manager use, and the mutation-method rejection; get_materialized_view added to the existing API-surface parametrizations
• Full tests/unit suite passes locally (5394 passed)
• Manually exercised against a local gRPC server: ReadRows/SampleRowKeys requests carry materialized_view_name (not table_name), rows are returned through the public API, and Table/AuthorizedView behavior is unchanged
• CI (docs build, lint, sync-up-to-date check across supported Python versions)

[gemini-code-assist]

Code Review

This pull request introduces support for read-only Materialized Views in both synchronous and asynchronous Bigtable data clients, including the necessary client methods, documentation, and unit tests. Feedback highlights a missing @property decorator on the abstract _request_path method in _DataApiTargetAsync for consistency, and identifies a bug in the async unit tests where non-iterable return values from read_row and row_exists are incorrectly subjected to async iteration, which silently swallows errors.

[mutianf]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces support for read-only materialized views in the Bigtable data client by adding the MaterializedView and MaterializedViewAsync classes, along with corresponding client methods, documentation, and unit tests. To accommodate this, the base classes _DataApiTarget and _DataApiTargetAsync were refactored to decouple table-specific attributes. Feedback on the changes identifies that the abstract method _request_path in _DataApiTargetAsync is missing the @property decorator, which should be added to ensure consistency with its subclasses and its synchronous counterpart.

[gemini-code-assist]

In _DataApiTargetAsync, the abstract method _request_path is missing the @property decorator. All of its subclasses (TableAsync, AuthorizedViewAsync, and MaterializedViewAsync) implement _request_path as a property, and the sync counterpart _DataApiTarget also defines it as a property. Adding @property here ensures consistency, prevents potential static analysis/type checking warnings, and matches the subclass implementations.

@property@abc.abstractmethoddef_request_path(self) ->dict[str, str]:

[mutianf]

Lgtm but we should add a systest (in a follow up PR).

[parthea]

System tests are failing at head for google-cloud-bigtable. I filed #17709 to follow up on it. This PR will be blocked until #17709 is fixed

Resolved