Update go deps: k8s + helm (+ memory increase)

[antgamdia]

Description of the change

As commented in previous PRs (#3501 (comment)), let's split this change into smaller PRs, so that we can better track which dep is causing the memory issue.

This PR is upgrading the minimum number of deps, but helm+k8s are bounded... so we have to bump them up at the same time.

Benefits

Updating deps + increasing from 216MI to 512Mi the memory of the kubeappsapis' pod.

Possible drawbacks

N/A

Applicable issues

• rel Update go dependencies #3501
• rel Memory issues in kubeappsapis/helm-related logic: getChart fetches the whole repo each time it's invoked #3567

Additional information

This PR supersedes #3632

According to what we discovered, this PR should pass the tests as is. I haven't included any of the fix attempts I performed in the aforementioned PR since they are not proven to be useful.

[antgamdia]

Todo: check OCI support is still working here

[absoludity]

Todo: check OCI support is still working here

Two scenarios:

1. helm 3.6 client uploads OCI charts to repo, can Kubeapps add the repo, sync and install.
2. helm 3.7 client uploads OCI charts to repo, can Kubeapps add the repo, sync and install.

If it turns out we can only do one of these, we may want to chat with the bitnami content team and decide when we upgrade to 3.7 in our code. If we can support both, great.

[antgamdia]

I've successfully tested this PR is not "breaking anything" related to OCI:

1. helm 3.6 client uploads OCI charts to repo, can Kubeapps add the repo, sync and install.

OK - I've installed our TAC OCI demo repo and I'm able to sync the repo and install chars from there.

2. helm 3.7 client uploads OCI charts to repo, can Kubeapps add the repo, sync and install.

OK - I've built the OCI artifact with Helm 3.7.1 and uploaded it to a harbor instance. Kind of fortunately, since we are copying the OCI code from the Helm codebase (as a temporary fix given that it is not -yet- exported), with a simple change (#3606 (comment)), we are able to support post-3.7 artifacts (and pre-3.7 ones as well)
However, w/o that fix, Kubeapps is not able to manage them, but it is out of the scope of this PR.

So, as a conclusion, this PR is not affecting the OCI support, thus being ready to be landed as soon it is +1ed.
(I'll be working on #3567 trying to avoid unnecessary expensive calls)

[absoludity]

thus being ready to be landed as soon it is +1ed.

Sorry, thought I already had.