WIP: feat: Implement customize hook

[mikebryant]

Implementation of https://metacontroller.app/design/customize-hook/

This doesn't need review yet, but might be interesting to others to see progress/ideas

[mikebryant]

@enisoc So I'm thinking that the way to do this is for parentController to create individual objects per Parent, and maintain all of these in memory?

And on a parent update, call the customize hook again, and recreate the parent object, like is done when a CompositeController is updated?

[enisoc]

Yeah that matches what I was imagining. Essentially we'd have an in-memory cache of customize hook responses (if the hook is defined) that gets invalidated whenever the parent spec changes. We don't want to invalidate the cache every time we update the parent status (which also updates metadata.resourceVersion), since that defeats the purpose.

The cleanest way to do that is to remember the metadata.generation of the parent object that resulted in a given customize response. This means the related resources feature will only work for CRDs with true /status subresource handling turned on, but I think that's ok as long as we document it (and maybe validate it at runtime?). In general, it's recommended for everyone to enable that on CRDs that follow the usual controller pattern.

[enisoc]

As a suggestion for prototyping: semantically we want this to be exactly like if we called the customize hook every time just before we call sync. You can prototype the API/UX and even write an integration test without worrying about the above caching yet. Just hard-code it to always call customize right before sync.

[Kritzefitz]

I whipped up an implementation for this on Kritzefitz:related-objects-impl based on the current state of this branch. Should I open a new pull request or somehow attempt to merge my work into this one?

[mikebryant]

@Kritzefitz Thank you!

Feel free to start a separate PR. I haven't had time to work on this lately, so please carry on :)