fix: unnecessary boxed primitives in AutoValue classes

[cushon]

Fixes

google-cloud-bigquery/src/main/java/com/google/cloud/bigquery/TableResult.java:42: error: [AutoValueUnnecessaryBoxing] property method com.google.cloud.bigquery.TableResult.getTotalRows() is primitive but parameter of setter method is not
    public abstract TableResult.Builder setTotalRows(Long totalRows);
                                        ^

See google/auto@328a25c

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #3459 ☕️

If you write sample code, please follow the samples format.

[PhongChuong]

/gcbrun

[PhongChuong]

Generally looks good.
Can you add an exception for the change in:
google-cloud-bigquery/clirr-ignored-differences.xml
And fix the conventionalcommits check.

[conventional-commit-lint-gcf]

🤖 I detect that the PR title and the commit message differ and there's only one commit. To use the PR title for the commit history, you can use Github's automerge feature with squashing, or use automerge label. Good luck human!

-- conventional-commit-lint bot
https://conventionalcommits.org/

[cushon]

Generally looks good. Can you add an exception for the change in: google-cloud-bigquery/clirr-ignored-differences.xml And fix the conventionalcommits check.

Thanks, done!

[PhongChuong]

@cushon , it seems like ci / clirr is still failing.
Sorry for the late reply.

[cpovirk]

@cushon is out for a couple more days, but I've been wondering: Would it make sense to leave the old method in place but as @Deprecated method that forwards to the new one? This PR isn't dangerous for anyone who recompiles against the new BigQuery version before using it, but it's dangerous for anyone who has previously compiled against BigQuery and then tries to use that precompiled jar with a new version of BigQuery at runtime. Given that, this PR would in principle justify a major-version bump, but I don't know how big the danger is in practice.

[cushon]

Would it make sense to leave the old method in place but as @Deprecated method that forwards to the new one?

Thanks, I'm going to try that out, I pushed another commit.

[cushon]

I'm still getting a clirr error, any ideas what why the exemption isn't sufficient?

Error:  Unable to locate enclosing class com.google.cloud.bigquery. for nested class com.google.cloud.bigquery.$AutoValue_Annotations
Error:  7013: com.google.cloud.bigquery.TableResult$Builder: Abstract method 'public com.google.cloud.bigquery.TableResult$Builder setTotalRows(long)' has been added

[cpovirk]

Suggested change

	<differenceType>7005</differenceType>
	<differenceType>7013</differenceType>

It looks like it's now complaining about a new abstract method, I assume on the theory that subclasses would have to implement it. Given that the only subclass here will be the one generated by AutoValue (I hope :)), we should be able to suppress that, too.

Since the old method continues to exist in this iteration of the PR, that suppression can replace the old one from the time of the method removal. With that change, JOB_TYPE=clirr .kokoro/build.sh appears to pass.