Convert kindsys to a basic interface

[ryantxu]

Status: WIP/POC... this is a pretty big change that is only possible to evaluate when looking at the source tree (diff is too big!)

This PR changes kindsys from a strictly cue+thema managed system to one that is defined by a golang interface, and can be implemented in with alternative approaches.

This takes a few big steps:

• [x] Introduces a root level kind interface for ResourceKind and ComposableKind
• [x] Moves the thema+cue specific implementation to new package: pkg/themasys
• [x] Adds a resouce kind implementation based on themasys
• [x] Adds a basic jsonschema implementation using https://github.com/santhosh-tekuri/jsonschema
• [x] Adds example valid+invalid data for playlists used in tests
• [x] Implements a playlist kind in three different ways:
  • using thema
  • using jsonschema
  • using raw golang structs
• [x] Adds some tests to compare these implementations

Before:

After:

TODO:

• [ ] JSON parsing cleanup... not yet sure if this needs to be a top level public thing, but useful for now
• [ ] Implement the "Migrate" functions for playlist
• [ ] Get themasys to use internal resource version for validation
• [ ] Benchmarks
• [ ] codegen import paths
• [ ] Basic registry implementation

FAQ:

Is this necessary?

Regardless how we choose to validate objects, we should build our tools against an interface that is forced to advertise its capabilities explicitly and that can be replaced/evolved as needed. The current surface area is too large/undefined/leaky to solidify into the foundation of all future grafana services.

What about existing kindsys usage and codegen?

Current kinds and codegen will continue to work after minor changes to the import package structures (TODO)

Future codegen packages can choose if they need to depend directly on thema+cue, or if access to a more generic kind interface is sufficient.

What about the shared static cuecontext?

This can still exist and work for thema based kinds. This context currently acts as a global registry -- in the future it could only be used to get access to cue based kinds.

[ryantxu]

I think the Resource interface will need some revisiting as we go on

Yes absolutely! my goal here was changing it as little as possible, because that is a project in itself.

[joanlopez]

Hey @ryantxu, what do you thing is still strictly needed to get this PR ready to merge? I see there's a (large) TODO list in PR's description, is that accurate? I'll be happy to help with any specific action to get it merged!