Add credential info to repository summary

[antgamdia]

Description of the change

This PR adds a slight modification to the Repos APIs: the GetPackageRepositorySummaries now supports an additional auth field. The proposed semantic is:

1. summary.auth == nil then the repo doesn't have any credentials.
2. summary.auth == &corev1.PackageRepositoryAuth{} then the repo has some sort of credentials to access it.

For saving time and k8s requests, is enough to send a non-nil value. However, it can also be turned into a boolean field, but wanted to open up the discussion with you all first.

Benefits

The UI will be able to display this info without fetching the details of each repo, which could be a lengthy operation (not in this PR though, this is just a modification in the API).

Possible drawbacks

N/A

Applicable issues

• fixes [Repository] add credential info to repository summary #4866

Additional information

[netlify]

✅ Deploy Preview for kubeapps-dev canceled.

Built without sensitive environment variables

Name	Link
🔨 Latest commit	c05da9a
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/62c5be568d8f980009f8db3a

[castelblanque]

The access level is a very useful information for a summary, thanks for the work!

I have my doubts regarding the type used, why PackageRepositoryAuth? The same goal could be achieved with a flag, or a string/enum containing different levels of access ("private", "public", or others if any).
Auth information itself (type, header, keys, etc) looks like a detailed data of the repo, not something to be shown in the summary.

[antgamdia]

I have my doubts regarding the type used, why PackageRepositoryAuth? The same goal could be achieved with a flag, or a string/enum containing different levels of access ("private", "public", or others if any).

I agree, there is no need to use the PackageRepositoryAuth. I went this way because I didn't want to make the summaries response differ so much from the detail resp. So using the same auth seemed fair enough. However, I agree, plugins won't be setting the PackageRepositoryAuth properties and it just becomes a boolean field.
Besides, with the implementation divergence, we have noticed in the auth header types, we better restrict the implementation possibilities.

What about a hasAuth field? I wouldn't want to add more terminology to the already existing one (hence avoiding terms like "accessLevel" or "isPublic"). WDYT ? I'm gonna start performing the changes while we come up with a good name for the field (it is always the most difficult part, hehe)

[castelblanque]

+1 to hasAuth field flag approach.
Alternative name idea: requiresAuth.
Thanks!

[castelblanque]

Awesome, thanks!