Reorganize pkg/dashboard/objects For Better Testability

[Bhargav-InfraCloud]

To make the package pkg/dashboard/objects more testable and for more overall coverage,

1. Induce interfaces for making the functions/methods modular to unit tests.
2. Mock the interfaces and tests. mockery can be used to create the mock code.
3. Move each interface functionality into a sub-directory of pkg/dashboard/objects to avoid import cycles issue.

@ Maintainers, I came across this while working on #139. I noticed, most parts of the package aren't (unit) testable without this. Please triage and let me know.

[undera]

The code is mostly testable, since it relies on Helm's mock objects paradigm. You can look at api_test.go to see how test fixtures work. Also, there are some tests in repos_test.go.
The test fixture is injected via cli.EnvSettings objects, where you can specify custom paths to repository index files and repository caches. In Helm sources, you can steal some ready-to-use fixture files: https://github.com/helm/helm/blob/main/cmd/helm/testdata/helmhome/helm/repositories.yaml

Please let me know if that makes sense

[undera]

I have added example test here: https://github.com/komodorio/helm-dashboard/blob/main/pkg/dashboard/objects/repos_test.go#L113

You can extend that test to cover the --devel situation.

[Bhargav-InfraCloud]

Thanks @undera for the sample test case. It worked out for the current --devel related changes. So no immediate requirement of discussion on this card.

However, I think we have more places in pkg/dashboard/objects where testing it through integration/API tests could be hard. And where unit tests might be a good way of performing checks.

Let's keep this card open. If I'm able to cover all scenarios using your way, I'll make this a tests card. Else, I'll submit a POC and we can further discuss.