[WIP] Unify Grafana Kind and Kubernetes Kind Formats

[IfSentient]

This is some initial scratch work to unify the way grafana kinds are represented in both the API Server responses/consumption (Kubernetes format) and in-code (Grafana format). This unification changes the structure of the metadata into a "composed set" of metadata which is sourced from both the kubernetes metadata and grafana common and kind-specific metadata, to which how they are implemented relies on the encoder (to preserve compatibility with CRD expression if/when needed). When using an aggregated API server for grafana kinds, additional subresources will be exposed for the non-kubernetes metadata, creating the following shape:

{
    "kind": "MyKind",
    "apiVersion": "ext.grafana.com/v1-0",
    "metadata": {
        "namespace": "foo",
        "name": "bar",
        ...additional standard kubernetes metadata...
    },
    "grafanaMetadata": {
        "createdBy": "a-user",
        ...additional standard grafana metadata...
    },
    "kindMetadata": { ...custom metadata for the kind, optional... },
    "spec": { ...spec for the resource... },
    "status": { ...status for the resource... },
    ...additional other subresources as supplied by the kind...
}

This format then is mirrored exactly in the UnstructuredResource, and is the "exposed" format via the Resource interface.

However, in order to allow for standard kubernetes tooling which may not understand the additional metadata subresources, the following must be done on encoding the resource into JSON/YAML/etc:

1. All (? maybe some specified subset?) keys in GrafanaMetadata must be JSON-encoded and placed in metadata.annotations with a key of grafana.com/X, where X is the GrafanaMetadata field key.
2. All (? maybe some specified-in-kind-definition subset?) keys in KindMetadata must be JSON-encoded and placed in metadata.annotations with a key of ext.grafana.com/X where X is the KindMetadata field key.
   These annotations are essentially read-only, as the source of truth is always the appropriate metadata subresource, but they are exposed via annotations so tooling can make use of them if incapable of handling non-standard subresources.
   This is somewhat analogous to how currently CommonMetadata has the non-kubernetes keys encoded into metadata.annotations and CustomMetadata has all keys encoded into metadata.annotations, but now with the additional ability to have non-string values for keys, as we no longer need to decode said annotations when unmarshaling.

There are additional concerns to be worked out, but I wanted to get this scratch space up to allow for conversation on the subject of properly unifying in-code (grafana) and API Server (kubernetes) forms of a Resource, as having to work with multiple forms creates what may be an undue mental burden.

Note that there still will be encoders/decoders for working with standard CRD's (basically using the same "encode" logic, but then inverting that logic for "decode"), but as these are only required for the grafana-app-sdk, they will likely live there.

[ryantxu]

it feels odd to qualify these as kube metadata... since they are essentially the identifiers. I was expecting kube metadata to be the more essoteric k8s specific things like:

• finalizers
• managedFields
• deletionGracePeriodSeconds
• etc

[IfSentient]

This is mainly to make them part of what kubernetes considers "metadata," i.e. what kubernetes puts in its metadata field, so that KubeMetadata is exactly compatible with the metadata field in kubernetes.

We could present a different interface via Resource, but I think we'd want generated code/UnstructuredResource to be formatted the same way the kubernetes object itself is.