VAULT-33074: add github sub-command to pipeline

[ryancragun]

Description

Investigating test workflow failures is common task that engineers on the
sustaining rotation perform. This task often requires quite a bit of
manual labor by inspecting all failed/cancelled workflows in the Github UI
on a per repo/branch/workflow basis and performing root cause analysis.

As we work to improve our pipeline discoverability and observability this PR adds a new github
sub-command to the pipeline utility that allows querying for such workflows
and returning either machine readable or human readable summaries in a single
place. Eventually we plan to automate sending a summary of this data to
an OTEL collector automatically, but for now sustaining engineers can
utilize it to query for workflows with lots of various criteria.

A common pattern for investigating build/enos test failure workflows would be:

export GITHUB_TOKEN="YOUR_TOKEN"
cd tools/pipeline
go run ./... github list-workflow-runs -o hashicorp -r vault -d '2025-01-13..2025-01-23' --branch main --status failure build

This will list build workflow runs in the hashicorp/vault repo for the
main branch with the status or conclusion of failure within the date
range of 2025-01-13..2025-01-23.

A sustaining engineer will likely do this for both vault and
vault-enterprise repositories along with enos-release-testing-oss and
enos-release-testing-ent workflows in addition to build in order to
get a full picture of the last weeks failures.

You can also use this utility to summarize workflows based on other
workflow statuses, a branch name, HEAD SHA, event trigger, github actor, etc. For
a full list of filter arguments you can pass -h to the sub-command.

Caution

Be careful not to run this without setting strict filter arguments.
Failing to do so could result in trying to summarize way too many
workflows resulting in your API token being disabled for an hour.

TODO only if you're a HashiCorp employee

• Backport Labels: If this fix needs to be backported, use the appropriate backport/ label that matches the desired release branch. Note that in the CE repo, the latest release branch will look like backport/x.x.x, but older release branches will be backport/ent/x.x.x+ent.
  • LTS: If this fixes a critical security vulnerability or severity 1 bug, it will also need to be backported to the current LTS versions of Vault. To ensure this, use all available enterprise labels.
• ENT Breakage: If this PR either 1) removes a public function OR 2) changes the signature
  of a public function, even if that change is in a CE file, double check that
  applying the patch for this PR to the ENT repo and running tests doesn't
  break any tests. Sometimes ENT only tests rely on public functions in CE
  files.
• Jira: If this change has an associated Jira, it's referenced either
  in the PR description, commit message, or branch name.
• RFC: If this change has an associated RFC, please link it in the description.
• ENT PR: If this change has an associated ENT PR, please link it in the
  description. Also, make sure the changelog is in this PR, not in your ENT PR.

[ryancragun]

An example of the output:

[github-actions]

CI Results:
All Go tests succeeded! ✅

[github-actions]

Build Results:
All builds succeeded! ✅

[tvo0813]

This is a very useful tool. The implementation looks good to me but I recommend having another reviewer assess it as well, given that I'm not highly familiar with Go.

[rebwill]

Very excited about this feature!

[charlesn-hc]

Great stuff 🚀

[tvo0813]

LGTM

[ryancragun]

Note

Even though this will only likely execute from the main branch I'm still backporting it to all active branches so that our pipeline utility stays in sync.