Fix CI Pipelines, remove references to HashiCorp Infrastructure

[cipherboy]

This fixes many pipelines and removes others that aren't necessary any more. In doing so, we had to:

• Fix the go modules to refer to the correct API versions,
• Move kubernetes integration tests into the main package,
• Remove all references to HashiCorp runners,
• Remove references to internal HashiCorp credential stores,
• Remove many references to Vault Enterprise,
• and then remove unnecessary actions.

I also added RISC-V 64-bit support while I was here. :-)

This pipeline can be seen in action on my fork: cipherboy#1 --> https://github.com/cipherboy/openbao/pull/1/checks

TODO:

• Check that builds work --> Builds do not work as they rely on dist/vault and hashicorp/actions-packaging-linux -- as part of Fork - Release Pipeline #153 we should replace those. I've fixed the build pipelines as part of this. Releasing is a different story; these builds aren't signed (for obvious reasons); I'm not sure if the Linux Foundation handles this for us or not.
• Ensure that CI executes for both Go and UI components.

Resolves: #31
Resolves: #42
Resolves: #152
Related: #153

[cipherboy]

@naphelps When you merge this, I think you can configure the branch protection rules on the repo to require that the format job of Run linters (defined in workflows/code-checker.yml) passes, resolving #29.

[Gabrielopesantos]

Are we going to continue with a single file per change approach instead of a single CHANGELOG file?
It also looks like the report_failed_builds script failed. Could it be missing permissions on the GITHUB_TOKEN?

[cipherboy]

@Gabrielopesantos If I recall correctly, GH actions doesn't provision a privileged token for pull requests from forks... Wonder how other projects handle this?

Upstream mostly had contributions from inside the repo, so it wasn't as much of a problem... Hmmm...

And to answer your question, yes, I think we're planning on using the changelog builder still.

[Gabrielopesantos]

@Gabrielopesantos If I recall correctly, GH actions doesn't provision a privileged token for pull requests from forks... Wonder how other projects handle this?

Upstream mostly had contributions from inside the repo, so it wasn't as much of a problem... Hmmm...

And to answer your question, yes, I think we're planning on using the changelog builder still.

Makes sense, I didn't consider that. Something like this might be what we are looking for. As far as I understood, it is possible to set workflows to only run once approved by someone with write permission.

[cipherboy]

@Gabrielopesantos said:

Makes sense, I didn't consider that. Something like this might be what we are looking for. As far as I understood, it is possible to set workflows to only run once approved by someone with write permission.

I think this page: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

states that the token for pull requests should have write permission. But its not clear to me why it failed:

Run ./.github/scripts/report_failed_builds.sh
gh: Resource not accessible by integration (HTTP 403)
{"message":"Resource not accessible by integration","documentation_url":"https://docs.github.com/rest/issues/comments#create-an-issue-comment"}
Error: Process completed with exit code 1.

Unless perhaps REPO is not set correctly? but this is set like:

build.yml:238:          REPO: ${{ github.event.repository.name }}

so I'm still suspicious of write permissions, IMO.