Initial App Manifest

[IfSentient]

What This PR Does / Why We Need It

This PR introduces the first step of the App Manifest, a concept to help clarify and drive app development. The App Manifest is the listing of the app's managed kinds and capabilities (admission, conversion) for those kinds. This PR introduces admission and conversion capabilities for kinds in the manifest, be leaves schemas unimplemented.

Added in this PR is the app package, which is where the App Manifest (as app.Manifest) lives, and where additional app-centric logic will reside for future features such as #385

app.Manifest is decoupled from the actual manifest data by having an app.ManifestData type which contains manifest data, and having the app.Manifest contain a pointer to said data (which can be nil), and a location for the data. This way, an app.Manifest can simply point to a file on-disk, or an API server location, without having to have the data loaded, and the consumer of the app.Manifest should understand how to fetch the app.ManifestData. This allows an app to not need to know the credentials to fetch the manifest data (such as kube config), but still be able to tell other components which may have such knowledge where to fetch the data (this is important in #385, as the App Provider will need to provide the manifest and a way of creating the App, but will not know how to talk to the API server, as the runner will be able to load those credentials).

Included in this PR is the generation of this in-progress initial manifest as both an API server CR, and as in-code app.ManifestData to use if and when the manifest type is not available in the API server. An app author can now specify their app's capabilities for admission and conversion for kinds via admission, mutations, and conversion in the apiResource field in CUE, and can optionally override those kind-wide defaults on a per-version basis with admission and mutation fields in the version (conversion is always only kind-wide, as all versions must be inter-convertable for conversion to be allowed). The test data has been updated with these additional fields for manifest generation testing. Two new files will now be generated on each grafana-app-sdk generate call: definitions/<app-name>-manifest.(json|yaml), and pkg/generated/manifest.go.

Relates to #353, which will be completed once the manifest contains the CRDs (schemas) as well.

[joeblubaugh]

This is cool - it would be great to include a 1st draft of documentation in this PR if you're able to; I'm not entirely sure as an app developer how I should interact with this.

[radiohead]

@IfSentient just to confirm, does this address #353 fully or do you want to do something else before we could consider that completed?

This is cool - it would be great to include a 1st draft of documentation in this PR if you're able to; I'm not entirely sure as an app developer how I should interact with this.

@joeblubaugh good point! I think it's a bit too early for the docs, as this doesn't yet make the manifest fully functional but we'll make sure to update the docs once it's ready for general usage!

[IfSentient]

@IfSentient just to confirm, does this address #353 fully or do you want to do something else before we could consider that completed?

I figured I'd wait to close that issue until the manifest also describes the schemas of kinds, as that's part of the description in the issue.