chore: Bump Buf to v1.28.0

[codingllama]

Update to the latest version.

• https://github.com/bufbuild/buf/releases/tag/v1.28.0

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[public-teleport-github-review-bot]

@codingllama See the table below for backport results.

Branch	Result
branch/v12	Failed
branch/v13	Failed
branch/v14	Failed

[codingllama]

I finally figured out why bot backports don't work for these kinds of PRs, the bot OAuth token needs permissions to touch the "workflow" scope.

@zmb3, do you think we could add that?

$ make backport PR=34539 TO=branch/v14,branch/v13,branch/v12
(...)
2023/11/14 10:54:00 please manually delete branch auto-backport/34539-to-branch/v14:
err: POST https://api.github.com/repos/gravitational/teleport/merges: 409 refusing
to allow an OAuth App to create or update workflow `.github/workflows/lint.yaml`
without `workflow` scope []. failed to merge 92abb10058a7fbf294e99ffc18f76345258f3874
into auto-backport/34539-to-branch/v14
exit status 1
make: *** [backport] Error 1

[zmb3]

Good find.

@jentfoo @adaadb6 WDYT?

[jentfoo]

Adding the workflow scope would significantly increase the permissions of the bot. I assume these workflow updates are relatively infrequent? cc @wadells as well

[codingllama]

Since we moved golangci-lint and buf to their respective actions workflow updates are reasonably frequent - whenever one of those gets a patch we need an update. I'd hazard it's close to a weekly afair. This change in procedure highlighted some difficulties, like the need for super approval to change those files and now the inability to use automated backports.

[codingllama]

Adding to the comment above, the actions bring us an immediate version change, unlike the buildbox/Dockerfile based solution we had before. This means that if a new golangci-lint version breaks the build, we catch that in the same PR that does the update. In the buildbox flow we first land the buildbox PR, then a new version gets published, and after that the update becomes "effective" (at some random future PR).