chore: update golang to 1.23

[tobybellwood]

This PR updates all usage of Go in the service to the latest major version available (1.23).

I've created an umbrella PR here to bring all the elements of the go update together - the actions, docker, makefile, go mod etc - it's really hard to manage them all via dependabot (without creating multiple PRs). Going forward, we will work in a scheduled PR for the Golang update every go release cycle. Given the inconsistencies between local versions, actions versions and upstream availability, we're opting for the most recent available version in the GitHub runner images (currently https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md) - which at Golang 1.23.2 is a patch release behind the current head.

I've also run a module update here (which may close some other PRs, too). This necessitated a license review for a couple of dependencies, which I've added to the local config here on review - again following the CNCF lead where possible and conducting a desktop assessment of any outliers.

I experimented with the fail_on_severity setting, but I feel that not seeing the vulnerabilities displayed below "critical" isn't enough information. Realistically, we're not in a place to be super-strict with vulnerabilities, but the intelligence provided here is valuable as part of the PR review process.

closes #402
closes #395
closes #380

[shreddedbacon]

Each of the individual pullrequests mentioned address parts, yet they all have problems with merging in isolation with one or so actions failing to pass due to a requirement of another pullrequest. It makes sense to try and consolidate updates like this.

We are also able to do single pullrequests that address just the version bump of Go across the actions, dockerfile, makefile in one, and then module dependency updates in another too, the two don't always have to be done at the same time.

[smlx]

I've also run a module update here (which may close some other PRs, too). This necessitated a license review for a couple of dependencies, which I've added to the local config here on review - again following the CNCF lead where possible and conducting a desktop assessment of any outliers.

This is the reason I asked about Lagoon licensing requirements the other day. We don't need to be as strict as the CNCF and only allowlist permissive licences. We can also allowlist e.g. MPL-2.0 and forget about having to individually specify MPL dependencies.

[tobybellwood]

Yes, once we get further through the services, we can probably move to a centralised more permissive allowlist. For a couple of them that we want to really encourage reuse/adoption (this, machinery and maybe some tasks), we probably can be a little tighter on excluding copyleft and have per-repo exclusions.