fix(Spanner): Make System Tests Work & Work Faster

[cy-yun]

This PR addresses the ongoing flakiness, high database provisioning overhead, and parallel-execution collisions of the Spanner system tests.

By consolidating test database provisioning, we reduce overall execution time through database reuse. Furthermore, we've removed structural bottlenecks (such as ID collisions and schema mismatches) that prevented these tests from running concurrently. (Parallelizing these tests with paratest to bring the time down to minutes locally is planned for a subsequent follow-up).

Below is a detailed breakdown of the specific problems and fixes implemented in this PR:

1. Test Database Provisioning Overhead & DDL Consolidation

• Problem: The system test suite was creating and dropping a new test database for every single test class, adding massive overhead to the already long execution time. Furthermore, individual test classes independently executed DDL statements (CREATE TABLE), causing Table already exists collisions when tests were executed against a shared persistent database.
• Fix:
  • Introduced TestDatabaseManager to provision a single shared Spanner test database and reuse it across all test classes.
  • Centralized all table and schema creation logic into unified traits: SystemTestCaseTrait.php (Standard Spanner) and PgSystemTestCaseTrait.php (Postgres Spanner).
  • Removed redundant CREATE TABLE and DROP TABLE operations from over a dozen individual test classes (e.g., BatchTest, WriteTest, PgBatchTest).

2. PostgreSQL DDL Compatibility & Schema Mismatches

• Problem: Reusing the same database across multiple test runs or classes caused PostgreSQL CREATE TABLE commands to fail because the tables already existed. Additionally, there was schema drift between individual tests.
• Fix:
  • Added IF NOT EXISTS to PostgreSQL DDL statements in the Pg*Test classes.
  • Reconciled schema drift and mismatches in PgQueryTest and PgPartitionedDmlTest to align exactly with the unified setup suite definitions.
  • Adjusted PgReadTest.php so that secondary index creation operates safely on shared databases without conflicting with concurrent tests.

3. Row ID Collisions on Persistent Databases

• Problem: Because multiple tests (like TransactionTest, OperationsTest, BackupTest) share the same Users test table, tests running sequentially on a persistent database were slowly filling up the table. Tests generated random keys using narrow ranges like rand(1, 346464), leading to frequent ALREADY_EXISTS errors during insertion due to the Birthday Paradox.
• Fix:
  • Updated the central SystemTestCase::randId() generator to use a massive 1-billion key space: rand(1, 999999999).
  • Replaced 11 instances of hardcoded, narrow rand() ranges in TransactionTest.php and PgTransactionTest.php to use the unified self::randId() helper.

4. BackupTest Reliability & Timeouts

• Problem: BackupTest operations were flaking due to transient errors, DEADLINE_EXCEEDED errors when GCP was slow, and improper polling configurations.
• Fix:
  • Updated long-running operation polling to use maxPollingDurationSeconds via an extended timeout loop for all Backup and Restore operations.
  • Refactored the timeout try/catch logic into a DRY pollWithExtendedTimeout($op) helper method in BackupTest.
  • Caught and ignored DEADLINE_EXCEEDED exceptions emitted during intermediate polling attempts.

5. Emulator Transaction Leaks

• Problem: When running tests against the emulator, unhandled or failed transactions were leaking and persisting on the emulator, causing subsequent test failures or slowdowns.
• Fix: Added an unhandled exception catch block in Database::runTransaction to rollback non-single-use active transactions before bubbling up the exception. Ensured ReadTest.php properly cleans up local emulator transaction state.

6. CI Configuration

• Problem: Spanner system tests were not executing in the standard CI pipeline.
• Fix: Enabled the Spanner test suite in phpunit-system.xml.dist now that stability is restored.

[bshaffer]

This looks really important, but this seems like a separate fix or a feature, as it's ensuring an active transaction which fails is rolled back appropriately. I think it should be in a separate PR (with tests)

[cy-yun]

Sure. made a separate PR: #9416