[BEAM-3218] Added Quota checks for PubsubMessage in PubsubBoundedWriter

[nguyent]

Follow this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

---

BEAM-3218
This PR adds a check in the PubsubBoundedWriter to ensure the size of a publish request is within the allowed quota. There's an additional change in the PR which also adds quota checks on PubsubMessage object creation, specifically ensuring a message does not:

• have more than 100 attributes
• attr key > 256 bytes
• attr val > 1024 bytes
• single message size > 10mb

based on the quotas here.

[aaltay]

R: @reuvenlax @chamikaramj

[chamikaramj]

Sorry about the delay. Reuven, could you review or pass to someone whose familiar with PubSubIO ?

[stale]

This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@beam.apache.org list. Thank you for your contributions.

[nguyent]

Bump, will address feedback here

[kennknowles]

We have turned on autoformatting of the codebase, which causes small conflicts across the board. You can probably safely rebase and just keep your changes. Like this:

$ git rebase
... see some conflicts
$ git diff
... confirmed that the conflicts are just autoformatting
... so we can just keep our changes are do our own autoformat
$ git checkout --theirs --
$ git add -u
$ git rebase --continue
$ ./gradlew spotlessJavaApply

Please ping me if you run into any difficulty.

[nguyent]

Closing in favor of BEAM-2660 #3619