Return the repo name in a carvel a pkg summary

[antgamdia]

Description of the change

As per #4543, it is now possible to populate the chip with the repo name of a carvel package. This PR just replicates the current approach for the Helm/Flux packages, that is, it does not introduces any big change with regards to how repos are referenced.
IMO, it should be carried out in a separate PR and leveraging the new Repo API.

Benefits

Carvel packages will also have a repo name, like the packages from Helm. Example:

Possible drawbacks

It has been implemented just returning Name: repo/pkgName, for instance: Name: tce-repo/grafana in the AvailablePackageSummary response, which is not consistent with the rest of the packages.
However, since we are going to refactor it as soon as we start integrating the new Repos APIs, I don't think it is such a big deal, but willing to hear your opinion.

Applicable issues

• fixes [carvel] Add pkg "repository" to the packges #4543

Additional information

Still a draft as I haven't written/adapted the tests yet.

[absoludity]

This PR just replicates the current approach for the Helm/Flux packages, that is, it does not introduces any big change with regards to how repos are referenced. IMO, it should be carried out in a separate PR and leveraging the new Repo API.

+1 for postponing a longer term solution using the new Repo API, but why not kill two birds with one stone and use the current approach in the Helm/Flux packages to encode it in the AvailablePackageReference.identifier, rather than the AvailablePackageSummary.Name field?

It was done that way in the other plugins for two reasons:

1. We needed a way to ensure the data was included in the response to the client (same purpose as here), and importantly,
2. It moves closer towards an AvailablePackageReference.identifier that is unique for a plugin (I say moves closer, because with Helm's and Carvels support of per-namespace repositories, even my-repo/apache` may not uniquely identify the available package).

Let me know if there's a reason you chose to encode it into the AvailablePackageSummary.Name field instead (also, wouldn't that make the name inconsistent with the same name in the AvailablePackageDetail.Name?). Otherwise, I'd be keen that we encode the repo name in the AvailablePackageReference.identifier, improving that field too?

It has been implemented just returning Name: repo/pkgName, for instance: Name: tce-repo/grafana in the AvailablePackageSummary response, which is not consistent with the rest of the packages.

Just keen to understand why not do it consistently with the other plugins (using the AvailablePackageReference.Identifier) - it's just as simple, but also improves that field as above.

Thanks either way!

[netlify]

✅ Deploy Preview for kubeapps-dev canceled.

Name	Link
🔨 Latest commit	f1307b1
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/62856aae088b5a00087c74a0

[antgamdia]

Let me know if there's a reason you chose to encode it into the AvailablePackageSummary.Name field instead
(...)
Just keen to understand why not do it consistently with the other plugins (using the AvailablePackageReference.Identifier) - it's just as simple, but also improves that field as above.

In fact, it was my first option, but then I noticed it would change the id we are requesting the pkg details with. Honestly, I wasn't aware (meaning I had forgotten it 😅 ) we wanted to move towards an FQDN with plugin and repo as the identifier, but the opposite (I thought we wanted to get rid of the repo for the helm/flux pkgs).

However, I'm 100% for using this FQDN as the id, so I have just pushed those changes (still missing tests, will address them soon, though)

[absoludity]

FWIW (not for this PR), but this is the code that is very much related to #4284

[absoludity]

Excellent, thanks