feat(bigtable): Rerouted MutateRows to use the data client

[daniel-sanche]

Migrating over @gkevinzheng PR from bigtable monorepo googleapis/python-bigtable#1290

Original description:

Changes Made:

• Rerouted MutateRows to use the data client's Table.bulk_mutate_rows function.
• Reworked error handling in Table.mutate_rows. Since we must return a list of Status objects, we process the list of errors obtained from the _MutateRowsOperation back into a corresponding list of error statuses.
• Reworked retries in Table.mutate_rows as follows:
  • retry.deadline -> operation_timeout
  • timeout/mutation_timeout -> attempt_timeout
  • A null retry deadline now defaults to the table default mutate rows operation timeout instead of being defined as no timeout. The docstring has been updated to reflect that. A retry deadline of 0.0 will still be a no-retry option, and is implemented by setting the list of retriable errors to the empty list, and the operation timeout to the default mutate rows operation timeout.
• A timestamp of None in set_cell, which is the default, will now generate a client-side timestamp representing the current time, rather than defaulting to using the server-side timestamp. The docstrings for this have been updated to reflect this.

Note to reviewers: This PR has already been reviewed and merged to a staging branch, with the intention of doing a single merge to main. We are now planning to slowly rollout these changes back to the main branch. Minimal re-review should be necessary

[gemini-code-assist]

Code Review

This pull request refactors the mutate_rows method in google/cloud/bigtable/table.py to delegate bulk mutation execution directly to the underlying data client implementation (self._table_impl.bulk_mutate_rows), allowing the removal of the legacy _RetryableMutateRowsWorker class and its associated helper functions. The review feedback correctly identifies a critical bug where an AttributeError will occur if retry is None, and points out the loss of defensive input validation checks for row types and table mismatches that were previously present.

[mutianf]

could someone configure timeout but not retry deadline and have timeout > default retry deadline?

[daniel-sanche]

The data client handles this by setting the attempt_timeout = min(operation_timeout, attempt_timeout)

[mutianf]

this already wraps the retry layer, correct?

[daniel-sanche]

I'm not sure I understand the question, but bulk_mutate_rows handles retries internally. The retry object passed in is just used to find deadlines and other arguments to pass through

Maybe we should raise an exception if the passed-in retry has fields set we don't support, like on_error? I think that was a potential breaking change Kevin raised. There's some functionality that isn't exposed, but may have been previously

[mutianf]

Yeah, I just wanted to make sure the data client handles retries

[mutianf]

Yeah, I just wanted to make sure the data client handles retries