epic: kcp aware konnector

[mjudeikis]

Backend now is kcp-aware when we migrated to multicluste-runtime.

In cases when once might want to do kcp-to-kcp, wethe need to have client (konnector) to be kcp aware.

This should allow to have both backend and konnector to act in multi-cluster aware way so one can have central component in kcp managing all clients, using kube-bind.

This should work with kubectl bind command, but because kcp does not allow anything to be deployed, it should use existing apis in the consumer workspace.

Depends on: #299

Objectives

• Consumers should be able to install a kube-bind client controller into their kcp environment.
• Consumers should be able to trigger binding an API via a kubectl plugin.
• Consumers should be able to consum

e kcp-based APIs from a remote kcp instance in their own kcp instance.

[alokkumardalei-wq]

@mjudeikis @mirzakopic @cnvergence , I would like to work on this, but before I want to clarify on some terms:

1. How do you actually want the konnector deployed for consumers in KCP? Since KCP workspaces can't run pods, should it run completely out-of-cluster or in some dedicated host cluster?
2. For kubectl bind, should the CLI just automatically detect that it's in a KCP context and skip trying to deploy the konnector pod? Right now, we're assuming it should just create the APIServiceBindings and stop there.
3. Does the konnector need the exact same APIExportEndpointSliceName parameters as the backend when we wire up multicluster-runtime? It feels like it might need a slightly different setup since it's acting as a consumer here.

Let me know guys if this looks good to you.