feature: automate helm version update process

[TerryHowe]

Add an automated periodic update job that checks for new Helm releases and updates the documentation accordingly.

Example output: #1953

How it works

The update job runs daily at 2am Pacific (9am UTC) and performs the following steps:

1. Check for new releases: Fetches the latest releases from the Helm GitHub repository
2. Filter releases: Ignores pre-release versions and focuses on stable releases
3. Update versions: Updates version numbers in config.toml for new minor releases of v3 and v2
4. Update dependencies: Updates the Go module dependencies in sdkexamples/go.mod for v3 updates
5. Regenerate documentation: Runs the Helm CLI documentation generator to update command references
6. Create pull request: If changes are made, creates a pull request with the updates

[scottrigby]

Nice work!

Today after releasing 3.19.0 and updating the docs with a combination of scripts and manual steps, i thought again that the entire release process (see Helm Release Checklist) could be more automated.

The release checklist itself could also use an update — there are things we just don't document checking, for example updating the version skew in other languages.

For this PR, i have some thoughts.

Split the functionality:

• I'm thinking there should be two scripts: one to poll for newer Helm versions, and another to update the docs in all the places we need for a new version
• the first can be on a cron, and can trigger the second passing the version as an arg to workflow_dispatch (and once we have full helm 4 releases, the same workflow can be triggered for each new Helm 3 and Helm 4 version)
• when the workflow_dispatch is manually triggered, the user can pass the version as the argument

☝️ what do you think about this?

More simplifications:

• no need to check for Helm 2 updates - there are no more
• we can remove docker call from the script - the workflow will run on ubuntu already (users who want to run manually can run the script from within a container if they wish)
• the readme for this script may be too verbose, especially given the details may change with the new docs site. I think it would be better for the make targets and script in general to be mostly self-documenting, with perhaps a mention in the main README.

Other details:

• all files need a newline at EOF
• the make target name should probably be update-docs-version or something more specific than update-docs (we are in fact only updating the version)

[TerryHowe]

I agree that "no need to check for Helm 2 updates - there are no more", but that can stand as a placeholder for v4 when that become available. I don't want to remove the capability to update two releases.

[TerryHowe]

Notes in italic about what is done and what is not or partial:

Split the functionality:

• I'm thinking there should be two scripts: one to poll for newer Helm versions, and another to update the docs in all the places we need for a new version (Instead of this, I've changed the script to work on one version at a time which simplifies it. Currently it is less than 200 lines.)
• the first can be on a cron, and can trigger the second passing the version as an arg to workflow_dispatch
• when the workflow_dispatch is manually triggered, the user can pass the version as the argument

More simplifications:

• no need to check for Helm 2 updates - there are no more (Consider it a placeholder for when v4 is available)
• we can remove docker call from the script - the workflow will run on ubuntu already _(this makes manual runs difficult)
• the readme for this script may be too verbose, especially given the details may change with the new docs site.

Other details:

• all files need a newline at EOF
• the make target name should probably be update-docs-version or something more specific than update-docs

[TerryHowe]

Updated for new site. Seems to work.