Introduce multicluster proxy mode for Kubeapps APIs

[castelblanque]

Summary Introduce a new setup for installing Kubeapps in which Kubeapps APIs can act as a proxy for all incoming requests to another Kubeapps APIs.

Background and rationale As decided in the Multicluster redesign document, Kubeapps will be required to be present in all workload clusters of a multicluster setup. At least Kubeapps APIs with plugins. The Kubeapps installation in charge of managing the multicluster (acting as a control plane) will have Kubeapps API in a "proxy" mode in which al business-related requests (e.g. create repo, list available packages, etc.) will be proxied as-is to the selected workload/target cluster.

Target cluster will expose a Kubeapps APIs that will receive those proxied requests, not needed to expose the K8s APIs endpoint.

Acceptance criteria

• Clusters set up for multicluster (clusters: value in chart) allow to provide, per cluster, the Kubeapps endpoint and not the K8s API endpoint.
• Chart has a flag value to start Kubeapps APIs with proxy mode enabled.
• Requests to Kubeapps APIs that have a specific header (to be decided) are proxied to the target cluster, instead of being processed internally. Only applies when the target cluster is different from the current cluster, and target cluster is among the list specified in charts value clusters:.
• All possible operations are computed by the target Kubeapps APIs and not the source Kubeapps APIs.