fix(bigquery-jdbc): align metadata methods error handling with spec

[keshavdandeva]

b/534730957

This PR aligns the Google BigQuery JDBC driver's error handling for metadata searches with the JDBC specification and matches general JDBC drivers.

The ignoreAccessErrors parameter was removed, as error handling is now correctly dictated by the API error code and resource type rather than the search scope.

• Graceful 404 Swallowing for Tables/Routines: 404 Not Found API errors encountered when listing tables/routines (e.g. from a deleted dataset) or performing targeted table lookups are now treated as search misses. The driver unconditionally swallows the 404 and successfully returns an empty ResultSet (0 rows) per JDBC spec.
• Strict 403 Enforcement: 403 Forbidden access errors are no longer silently swallowed during broad scans. Any access denial immediately aborts execution and throws a SQLException, strictly adhering to the JDBC specification and other JDBC drivers.
• Project-Level 404 Throwing: If a broad dataset scan fails with a 404 Not Found (indicating the parent project is inaccessible or missing), the driver explicitly throws a SQLException to emulate general JDBC drivers behaviour

[gemini-code-assist]

Code Review

This pull request refactors the BigQuery database metadata processing logic by removing the 'ignoreAccessErrors' flag and simplifying the error handling for 404 exceptions across multiple methods. The reviewer suggested improving code readability by formatting method calls with multiple arguments across separate lines, as the current single-line formatting negatively impacts maintainability and adherence to standard style conventions.

[keshavdandeva]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the BigQuery JDBC metadata retrieval logic by introducing a 'throwOn404' flag to the 'findMatchingBigQueryObjects' method and related helper functions. This change centralizes the handling of 404 errors, allowing for more granular control over whether a 404 should be swallowed (returning an empty list) or propagated. The reviewer correctly identified that these significant changes to error handling logic for 403 and 404 status codes lack sufficient test coverage and requested additional unit tests to verify the new behavior.