Set up CD to release to GitHub Pages

[florisvdg]

This PR adds a CD pipeline for the Helm chart and also transitions the Helm repo model to use GitHub Pages.

Impact of this transition on the Git repo and on the Helm repo:

New Helm repo url

• Old: https://raw.githubusercontent.com/1Password/connect-helm-charts/main
• New: https://1password.github.io/connect-helm-charts

No more generated files / artifacts in source control

With the new model, we can remove the .tgz files and the index.yaml file. For backwards compatibility, I didn't remove the index.yaml file just yet (which I will in a future PR). Instead, I've changed the tar urls it points to, so that old repo url still works without the tars in source control anymore.

GitHub Pages setup

Here's how this works: there's now a persistent branch called gh-pages, whose file tree gets served by GitHub Pages. It only has an index.yaml file (served at https://1password.github.io/connect-helm-charts/index.yaml), because that's all Helm needs. The index file points to tars stored as GitHub Release assets. For backwards compatibility, I've manually uploaded the existing tars to the corresponding GitHub Release.

New release process and tagging model

To do the release, we're using the official Helm chart-releaser CLI and accompanying action. This will keep an eye on main for new chart versions (i.e. different version in Chart.yaml compared to the previous chart tag) and automatically create a new tag+release on GitHub with the tar. Then, it updates the index.yaml file on the gh-pages branch.

Using the chart-releaser tooling does impose some differences to the way we've done things before, noticeably:

• Releases/tags are now done 'per chart' instead of for the entire repo, so they'll be composed of both the chart name and the version: <chart name>-<chart version>. Here's an example of how that will look (this was done on a fork):

• The charts have to be in a subdirectory, so I had to move connect/ to charts/connect/
• With the release automated, we can delete the scripts to do a local release. Open point of discussion is still what to do with the changelog.

[florisvdg]

We should wait with merging this until the next release is prepped, because otherwise it'll try to re-release v1.1.0. So converting to a draft for now to avoid an accidental merge.

[florisvdg]

I've disabled the automatic workflow trigger, so we can already merge this.