feat: add optional runtimeclassname

[jsoref]

Description

Add runtimeClassName to enable using oauth2-proxy with gvisor (see https://gvisor.dev/docs/tutorials/kubernetes/#wordpress-deployment)

Checklist:

• I have bumped the version in the Chart.yaml according to Semantic Versioning.
• I have updated the documentation/CHANGELOG at the bottom of the Chart.yaml
• I have signed off all my commits.
• (Optional) I have updated the Chart.lock for dependency updates
• (Optional) I have implemented helm tests for new feature flags

[jsoref]

A general comment about version bumping, we internally set up a workflow to deal with it instead of requiring each dev to guess the next available version. It lets us merge things much faster. Devs just declare the kind of version bump they want with a file in a certain directory and it is used to generate the commit for the version bump (different directories for different kinds of bumps).

That same thing could also manage the changelog bit which will always conflict here.

Anyway, I'll see if I can find time today or Monday for this. But I can't make guarantees.

[jsoref]

The two actions that work together are more or less:
https://github.com/GarnerCorp/build-actions/tree/main/bump-version
https://github.com/GarnerCorp/build-actions/tree/main/next-version

The code more or less works like this:

on:
  push:
    branches:
      - main*
  pull_request:

permissions:
  contents: read

jobs:
  ci:
    if: github.event_name == 'pull_request' || !contains(github.actor, 'something')
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      id-token: write
    steps:
      - name: Checkout with push key
        if: github.event_name == 'push'
        uses: actions/checkout@v6
        with:
          ssh-key: "${{ secrets.PUSH_KEY }}"

      - name: Bump Version
        if: github.event_name == 'push'
        uses: GarnerCorp/build-actions/bump-version@main
        id: version
        with:
          version-type: "node"
          version-file-path: "package.json"
          git-name: "something"
          git-email: "something@example.com"
          major: changelogs/major
          minor: changelogs/minor

There's some fancy dancing involved, and we don't use it for public repositories, so we aren't particularly worried about things, but, ...

You could do it in various other forms, e.g. having a release workflow that only runs on dispatch or something.

I've been meaning to do a blog post writing up this workflow (probably on dev.to), but I haven't yet, so this is probably the first time I've publicly described it.

• The github.actor guard corresponds to the user tied to the PUSH_KEY and is designed to prevent eating its own tail.
• The main* bit enables some amount of testing for changes to the workflow w/o burning real version numbers.