chore(bigquery-jdbc): Force integration tests to use per-run datasets

[logachev]

Currently tests rely on existing datasets. Some of them also try to create tables without unique names (e.g. FakeTable) which results in failures if two integration tests are running concurrently.

This change eliminates dependency on JDBC_INTEGRATION_DATASET and JDBC_INTEGRATION_DATASET_2 and relies on the new unique dataset that is removed up after the run.

This will also allow us not to rely on table cleanup as the entire dataset will be removed.

[gemini-code-assist]

Code Review

This pull request refactors the integration tests to use dynamically generated shared datasets instead of hardcoded dataset names, introducing automatic cleanup via JVM shutdown hooks. The reviewer identified that sharing a single dataset across multiple test classes can lead to test interference and metadata query pollution. To resolve this, the reviewer suggested introducing a getUniqueDataset() helper method in ITBase to provide isolated datasets for test classes that do not need to share resources.

[gemini-code-assist]

Sharing a single dataset across multiple concurrent or sequential test classes can lead to test interference, especially for metadata queries (like DatabaseMetaData.getTables) which list all tables in a dataset. Since tables created by other tests are not cleaned up until JVM shutdown, they will be visible to any test querying the shared dataset.

To ensure proper test isolation, we should introduce a getUniqueDataset() helper method in ITBase that creates a new, isolated dataset for each test class's private tables, while registering it for automatic cleanup on shutdown. This allows test classes to use isolated datasets for their own tables, while still using getSharedDataset() for shared resources (like constraints and procedures).

    return sharedDataset2;
  }

  public static String getUniqueDataset() {
    String uniqueDataset = "JDBC_IT_UNIQUE_" + System.currentTimeMillis() + "_" + (100 + new java.util.Random().nextInt(900));
    try {
      setUpDataset(uniqueDataset);
      registerShutdownHook(uniqueDataset);
    } catch (InterruptedException e) {
      Thread.currentThread().interrupt();
      throw new RuntimeException(e);
    }
    return uniqueDataset;
  }

[gemini-code-assist]

By assigning both DATASET and CONSTRAINTS_DATASET to ITBase.getSharedDataset(), they point to the exact same dataset. This causes the constraints tables and the metadata test tables to coexist in the same dataset, which can interfere with metadata queries that expect these datasets to be isolated.

Using the new getUniqueDataset() helper ensures that DATASET and DATASET2 are isolated, unique datasets for this test class, while CONSTRAINTS_DATASET correctly points to the shared dataset containing the pre-created constraints tables.

Suggested change

	DATASET = ITBase.getSharedDataset();
	DATASET2 = ITBase.getSharedDataset2();
	CONSTRAINTS_DATASET = ITBase.getSharedDataset();
	DATASET = ITBase.getUniqueDataset();
	DATASET2 = ITBase.getUniqueDataset();
	CONSTRAINTS_DATASET = ITBase.getSharedDataset();

[gemini-code-assist]

Using getSharedDataset() here means ITResultSetMetadataTest shares its dataset with other test classes. Any tables created here will persist until JVM shutdown and could interfere with metadata queries in other tests. Using getUniqueDataset() ensures complete isolation.

Suggested change

	DATASET = ITBase.getSharedDataset();
	DATASET = ITBase.getUniqueDataset();

[gemini-code-assist]

Using getSharedDataset() here exposes ITStatementTest's tables to other tests running in the same JVM. Using getUniqueDataset() ensures proper test isolation.

Suggested change

	DATASET = ITBase.getSharedDataset();
	DATASET = ITBase.getUniqueDataset();

[gemini-code-assist]

Using getSharedDataset() here exposes ITConnectionTest's tables and procedures to other tests running in the same JVM. Using getUniqueDataset() ensures proper test isolation.

Suggested change

	DATASET = ITBase.getSharedDataset();
	DATASET = ITBase.getUniqueDataset();