[Task]: Rebase kcp repos to kubernetes v1.33

[ntnn]

Overview

Depends on the client-go update to code-generator/v3: kcp-dev/client-go#47

This page has a guide: https://docs.kcp.io/kcp/v0.27/contributing/rebasing-kubernetes/

Implementation Details

Will be filled with links as it goes on:

• apimachinery https://github.com/kcp-dev/apimachinery/tree/kcp-1.33.3
• code-generator https://github.com/kcp-dev/code-generator/tree/kcp-1.33.3
• client-go https://github.com/kcp-dev/client-go/tree/kcp-1.33.3
• kubernetes https://github.com/ntnn/kubernetes/tree/kcp-1.33.3
• kcp Rebase to kube 1.33.3 kcp-dev/kcp#3511

Notable Changes:

• Getting initial objects via Watch has been disabled: Stop exposing list-via-watch from the server kubernetes/kubernetes#131359
  Can only be enabled through a FeatureGate

Completion Checklist

• Code implemented and tested: Rebase to kube 1.33.3 kcp-dev/kcp#3511
• updating kube rebase docs taking the move to monorepo in account and adding new author on substantial changes
  Update kube rebase docs kcp-dev/kcp#3564
• protobuf for kube-native types and CBOR for all
  KCP can technically use protobuf (and has no problems doing so when the client sends protobuf [or CBOR], see e.g. https://github.com/ntnn/kcp-cbor-proto-tester/) - however having PrefersProtobuf enabled in kcp-dev/kubernetes errors in the apiextension server where it is trying to decode protobuf as JSON. I'm not sure why as selecting the correct decoder should have been handled by the headers.
  While protobuf is less interesting as it only benefits kube native types CBOR is more interesting and our patches currently do not take CBOR in account, e.g. here: https://github.com/kcp-dev/kubernetes/pull/170/files#diff-39e2ff2eeff49f0b9c7d72720178f54e0c233226f912db61d3d08dcd551278de
  I made some tests with both and ultimately decided that it is better to leave this is a separate issue.
  I tested some more and the breaking point is still that the negotiation seems to fail. I think it'd be better to leave this until CBOR is the default.
• gc worker lock
  Kube switched to using a lock-less GC in 1.32 which was patched back in for KCP; when talking about performance problems it came up that we could just drop that patch and see if that produces any problems. Having just tagged 0.28 this might be a good opportunity to do that.
  feature: lock-less (cluster-aware) garbage collector kcp-dev/kcp#3555
• converter
  The converter has many changes and the patches for it do not apply without conflicts even though there were no changes upstream. Also three of four helper functions are identical to upstream helpers, one only has minor changes. Much of the logic in the converter is also present in the webhook_converter. This patch could probably be rewritten to be less intrusive and to merge easier for future rebases.
  Actually this is wrong - this was only the case because I erroneously omitted a commit I believed was merged upstream, which resulted in this issue: bug: API conversion does not work for built-in types (APIBindings...) kcp-dev/kcp#3545
• applyconfiguration
  In KCPs hack/update-codegen-clients.sh is a comment about using generate-groups.sh once Add applyconfiguration generator to code-generator script kubernetes/kubernetes#114987 is merged. The PR has been merged a while ago, maybe this can be addressed.
  cleanup: Omit installing applyconfiguration-gen / client-gen in codegen kcp-dev/kcp#3563
• validation-gen
  See UPSTREAM: <carry>: Drop validation-gen  kcp-dev/kubernetes#169 and specifically the commit kcp-dev/kubernetes@934d467 (#170) for details - in essence k/k has added validation-gen for declarative field validation from struct tags rather than the handwritten validation. But that fails in the kcp-dev/k fork as the go.mod rewrites do not work in the fork.
  From what I gather this is only intended for kube-native types.
  feature: validation-gen in kcp-dev/k kcp-dev/kcp#3562
• Update all context.WithCancel(context.Background()) calls in tests to t.Context() -> Update to use testing.T.Context kcp-dev/kcp#3535