fix(bigtable): ensure deadline is respected for read_rows_sharded

[daniel-sanche]

The read_rows_sharded tests were flaky. It seems this mostly came down to not having a mutex on the timeout generator, which isn't completely thread safe in the sync context. This ensures that the timeout is always accessed sequentially

Also increase the timeout in the test, to prevent future flakes

[gemini-code-assist]

Code Review

This pull request introduces a lock (gen_lock) to ensure that rpc_timeout_generator is thread-safe during sharded row reads in both the async and sync clients. Additionally, it updates the unit tests to use CrossSync.sleep and CrossSync._Sync_Impl.sleep instead of asyncio.sleep, and increases the test operation timeout. A review comment correctly identifies a missing import of CrossSync in the async unit tests, which would lead to a NameError during execution.

[gemini-code-assist]

The test now uses CrossSync.sleep instead of asyncio.sleep, but CrossSync is not imported in this test function. To avoid a NameError during test execution, please import CrossSync from google.cloud.bigtable.data._helpers.

Suggested change

	from google.cloud.bigtable.data._helpers import _CONCURRENCY_LIMIT
	from google.cloud.bigtable.data.exceptions import ShardedReadRowsExceptionGroup
	from google.cloud.bigtable.data._helpers import _CONCURRENCY_LIMIT, CrossSync
	from google.cloud.bigtable.data.exceptions import ShardedReadRowsExceptionGroup