Add GetPackageRepositories implementation for carvel and helm-fluxv2

[absoludity]

Description of the change

This was just to rename the helm_operator plugin to helm_fluxv2, but while there, I've added a demo implementation for the GetPackageRepositories method for both.

From the updated README, with the appropriate resources on your cluster you can now:

$ curl -s http://localhost:8080/plugins/helm_fluxv2/packages/v1alpha1/packagerepositories | jq .
{
  "repositories": [
    {
      "name": "bitnami",
      "namespace": "flux-system",
      "url": "https://charts.bitnami.com/bitnami"
    }
  ]
}

$ curl -s http://localhost:8080/plugins/kapp_controller/packages/v1alpha1/packagerepositories | jq .
{
  "repositories": [
    {
      "name": "repo-name.example.com",
      "namespace": "",
      "url": "foo.registry.example.com/repo-name/main@sha256:cecd9b51b1f29a773a5228fe04faec121c9fbd2969de55b0c3804269a1d57aa5"
    }
  ]
}

Benefits

Provides an example of an API call implemented by two plugins (needed for #2775). Renames helm flux plugin more appropriately (@gfichtenholt found helm_operator is from a pre fluxv2 version). Provides an example so @gfichtenholt can think about GetAvailablePackages for helm-fluxv2 (though as I mentioned on slack, this may be more work than we'd thought, depending whether fluxv2 actually exposes something analogous - afaict so far, it only creates a HelmChart object when a user installs from a repo, happy to jump in there to help as needed).

Possible drawbacks

N/A

Applicable issues

• fixes Implement kapp-controller/flux Kubeapps APIs for GetAvailablePackages #2775

Additional information

Next up for me:

• Start using this to help with the design of the API requests across plugins
• investigating the fake dynamic client so we can write useful unit tests
• potentially try a generic API call above the plugins, such as /core/packages/v1alpha1/GetPackageRepositories to show how we could return objects across plugins (chatted with @migmartri about this).
  But I'll discuss the above as part of our iteration planning next week.

[gfichtenholt]

I would probably just go with fluxv2, i.e. drop "helm". Based on their docs Flux supports more than just helm, they also support Git repositories with artifacts, as well as Amazon-style buckets with artifacts.

[absoludity]

True, I was thinking that we're only interested in the helm support, but we may want to support any repositories/packages. Note that we'd need to then include something like a resource type field (group/version/name) so if we're returning results including both HelmRepositories and GitRepositories (?), they can be recognised as such (I'll just rename in this PR). Let me do the rename...

[absoludity]

Done. :)

[gfichtenholt]

spelling and/or wording?

[gfichtenholt]

I viewed and I am ok with the changes. I don't have enough expertise on grpc and protobuf to be able to comment constructively at this point, but I will get there someday :-)

[gfichtenholt]

sorry missed one question. In earlier version of the PR, I saw a change you made in deploy-dev.mk to deploy kapp-controller to a cluster. I don't see that anymore in this list of files, nor do I see a target to deploy flux v2 Is that deliberate?

[absoludity]

sorry missed one question. In earlier version of the PR, I saw a change you made in deploy-dev.mk to deploy kapp-controller to a cluster. I don't see that anymore in this list of files, nor do I see a target to deploy flux v2 Is that deliberate?

That was in the previous PR, let me add a similar one with the flux command I used to install the flux CRDs etc., as it's also useful as documentation of what version etc. was being used.