Ease Runtime Extension implementation by providing exported util packages

[sbueringer]

Goal of this issue is to make it easier to implement RuntimeExtensions by exporting useful packages.

Note: We gathered some experience writing RuntimeExtensions by implementing a test extension for our e2e tests.

I would propose to:

• move internal/runtime/catalog to exp/runtime/catalog
  • I think catalog is stable enough to be exported.
• move test/extension/server to exp/runtime/server
  • While the server package is pretty new, I think we can still iterate on it given the API guarantees for the exp package.
  • By exporting the package now we can gather feedback from RuntimeExtension authors and evolve it over time.

By moving these packages it becomes a lot easier to implement RuntimeExtensions. In fact looking at our test extension it would be enough to implement a Runtime Extension for lifecycle hooks.

It should also help to implement RuntimeExtensions for topology mutation but I think we need a follow-up to:

• export a package which makes it easy to work with variables
• export a package (possibly the same) which helps folks to deal with the topology mutation hook requests/responses and generate patches. The basis for this can be: the variable package and lib.go from our test extension.

/kind feature

[sbueringer]

@fabriziopandini @chrischdi @ykakarap @killianmuldoon Opinions?

[fabriziopandini]

I'm +1 because this will allow user feedback on those packages
The catalog is ~stable since first prototypes, Server we can iterate given experimental contract.

[killianmuldoon]

+1 I think we should make the experimental contract very explicit, and after that try to offer as much functionality (in as few public methods) as possible. +1 to both catalog and the test extension.

[ykakarap]

+1 to moving both the packages. Would simplify implementing an extension if we access to catalog and the server libraries.

I have some bandwidth and I am happy to help with the refactoring.

/assign