fix(bqjdbc): pass rowsInPage with TableResult

[Neenu1995]

b/511229401

This PR introduces the rowsInPage metadata to TableResult and ensures it is populated for all pages (both the first page and subsequent pages fetched via pagination).

Previously, metadata about the number of rows in the page was not easily accessible or propagated across multiple paginated requests (e.g., when calling getNextPage()). This change:

1. Adds a rowsInPage field and builder method to the @AutoValue TableResult class.
2. Populates rowsInPage during initial page creation in BigQueryImpl and empty results in Job.java.
3. Updates TableResult.getNextPage() to calculate the size of values for subsequent pages via Iterables.size (which is $O(1)$ for materialized lists) and sets it on the returned TableResult pages.
4. Updates unit test assertions in TableResultTest.java and SerializationTest.java to verify that rowsInPage is populated and propagated correctly.

Key Changes

• TableResult.java: Added getRowsInPage(), builder method setRowsInPage(), and updated getNextPage() to pass down the calculated row count for the next page.
• BigQueryImpl.java: Set rowsInPage on initial query results page creation.
• TableResultTest.java: Added assertions to verify that rowsInPage is correctly populated for both the first page and subsequent pages.

[gemini-code-assist]

Code Review

This pull request introduces a rowsInPage field to the TableResult class, allowing for more accurate tracking of the number of rows in a specific results page. This field is integrated into the JDBC driver's read ratio calculation and various TableResult construction points. Feedback includes a critical fix for the equals method to use Objects.equals for string comparison of queryId and a suggestion to ensure rowsInPage is populated during pagination for consistency.

[logachev]

Can we guarantee somehow that it would be using .size() to avoid O(N) here?

[Neenu1995]

We can guarantee $O(1)$ performance because the row values in TableResult pages are always materialized into an ImmutableList under the hood. Since ImmutableList implements Collection, any size check—whether through our explicit instanceof check or Guava's Iterables.size—calls the list's size() method directly. This allows Java to look up the count instantly instead of looping through each row one by one.

But if we want we can add an explicit instanceof check here. Should I add it?