Use GitHub Actions for most release automation

[cpovirk]

Currently, we have a shell script that we use to release Guava (and various of our other projects). It could be further automated even in its current form (e.g., to automatically close and release in Sonatype), but we could go a step further and convert most of the process to GitHub Actions. That would give us easy access to whatever OpenJDK we want to build with.

Guava has at least two actions that we want to perform in our internal repo: We update @since tags, and we bump the version number in our README. Those steps couldn't be part of the release process. Still, we could automate everything after that. Maybe we can even eliminate or automate those two steps:

• At this point, we're unlikely to remove APIs, so maybe we can start filling in "@since 33.3.0" instead of "@since NEXT?"
• Maybe we can find a way to store the version number only externally, whether through Copybara magic, a YAML file, or some combination of options.

We may also need to deal with an occasional hiccup or two in the release process, such as the need to rebase on gh-pages (internal bug 221894165).

---

cushon@ has shared some of what Error Prone does:

https://github.com/google/error-prone/blob/master/.github/workflows/release.yml#L42-L48 \ https://github.com/google/error-prone/blob/9e0fbf705dc98faf2a8ac88cbdb1facc0ba18696/pom.xml#L284-L292

It's using a sonatype plugin to handle the uploads: https://help.sonatype.com/en/configuring-your-project-for-deployment.html

[cpovirk]

For authentication, we'd apparently soon need to use a user token instead of username+password. That sounds like it has probably always been the better solution, anyway.