Connect up helm chart endpoints

[foot]

What changed?

• Server: Add a new controller that watches HelmReleases and populates the SQLite cache.
• API: Add layer to /v1/charts/list response
• API: Add RBAC check to /v1/charts/list and /v1/charts/values
• UI: Switch to using /v1/charts/list and /v1/charts/values endpoints
• Tooling: Fixes for cross-compiling to linux from darwin (NATIVE_BUILD=1 tilt up)

Why was this change made?

• Next step in moving to Multi-Cluster index.yaml / values.yaml requests
• Only queries the management cluster right now NOT other leaf clusters
• Keeps existing profiles system in place to be removed in a follow up.

How did you validate the change?

• Unit tests
• Manual testing
• Smoke tests still pass.

Follow ups

• Remove old /v1/profiles endpoints or adapt them to use the new cache
• Start new multiwatcher for populate sqlite cache with index.yamls for every cluster
• Merge Expose known clusters from the clusters-manager weave-gitops#2918 and update GetValuesForChart to use it

[foot]

Disabled leader-election and metrics etc here as I don't think we need them.

Leader election can be useful during upgrades but

• Probably will deploy with pod-local storage (?) so each clusters-service that ends up running will have an independent cache.
• Multiple clusters-services writing to sqlite on a PVC is probably fine too. Might bump into some "database already open / locked" w/ multiple processes but controller retrying should eventually resolve.

Metrics need to open ports (?) so doing that for every cluster doesn't sound great.

The "manager level" still seems like the correct level to spawn for each cluster https://book.kubebuilder.io/architecture.html

Is this a bad idea @bigkevmcd ?

[sarataha]

LGTM! 🥇 🎉