Add logical cluster migration

[ntnn]

Summary

This PR adds migrating logical clusters between shards.
The intent of an admin to migrate an LC is expressed using LogicalClusterMigration.migration.kcp.io.
The object is replicated to the cache-server and used to synchronize the migration between the origin and destination shard.
The destination shards pulls the data of the migrating LC using the LogicalClusterDump type through the migrating VW.
The migrating VW was added only to not put the pressure of the migration on the front-proxy as well.

More details on the process are in the reconciler package docs.

The happy path works but it still needs some resilience and we'll probably hit some real blockers once we try it on real infrastructure.
Also I haven't put in guard rails yet for who can actually create lcmigration etcpp. But I don't want the PR to get even bigger than it is.

What Type of PR Is This?

/kind feature

Related Issue(s)

Fixes #

Release Notes

Added migrating logical clusters between shards gated by the LogicalClusterMigration feature gate

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign embik for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS
• config/crds/OWNERS
• staging/src/github.com/kcp-dev/sdk/apis/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ntnn]

/test pull-kcp-test-e2e

flake

 === FAIL: test/e2e/authorizer TestShardMetricsEndpoint (30.36s) 

[gman0]

Why doesn't handleBatchDeltas need to special-case ReplacedAllInfo deltas, similar to how handleDeltas does?

[gman0]

Is it possible the handlers that use this informer are still processing this object? It sounds a bit racy :D I wonder if it could be moved into the controller (the caller, using this informer), purge outside of the reconcile func while holding a lock. So that all threads can observe the same events.

[gman0]

... causes the underlying reflector to perform a full relist IF the said reflector also implements this magical forceRelister interface.

I think more context could be added into the comment. With the single user of this being the LC migration controller, it's not super obvious (without further digging) WHY is this even here.

[gman0]

A nit, but could this be thisWatch, just watch or something like that? :D While reading, I was wondering that if this is THE active watch, I was looking for where is the other, inactive watch.