Consistent GVK attribute export across all metric types

[christophrj]

What would you like to be added:

Right now metric attributes are not consistently exported in terms of their GVK attributes which is confusing to end users and also a potential source for errors.

Metrics and FederatedMetrics export GVK attributes based on the spec.target fields and kind as "resource": https://github.com/openmcp-project/metrics-operator/blob/main/internal/orchestrator/metrichandler.go#L135

ManagedMetrics and FederatedManagedMetrics export GVK attributes based on the observed resource and kind as "kind": https://github.com/openmcp-project/metrics-operator/blob/main/internal/orchestrator/managedhandler.go#L62

This issue requires further alignment but as a starting point I suggest the following 2 options:
(A) all metrics export GVK attributes based on the spec.target fields kind as "kind" -> simple and 1 to 1 mapping between "cluster" and "datasink" metric. downside is obviously the missing granularity of the observed CustomeResources
(B) A plus GVK values of CustomResources where both are explicitly labeled as Target GVK and CR GVK -> more complex but enables detailed view of the underlying metrics CRs in the DataSink.

Why is this needed:
To implement consistent behavior across all metric types and prevent bugs based on those inconsistencies.

[HannesDyballa]

I think once we have done most of what I propose in #140 and especially #145 , we can decide between these 2 options, which I think make more sense.

Let the user decide, but always export the spec.target fields
If a user has specified to only monitor for a specific group, I would expect that this is always set. And if the user want more granular data, he can just export "kind" with a dimension.
This has the limitation, that you can not export version or group, but just "apiVersion". The user would need to implement downstream processing.
I think here we have the opportunity to add some specific FieldPath, which deviates from the standard JSONPath implementation, similar to the special case of'.' described in #134.
We could think about 'group' and 'version', which are not fields on the resource, but get calculated.

Always export GVK of CR
We can just always export the GVK of the CRD, which gets exported, which would lead to a higher metric cardinality.
I would be against this.

[MichaelSp]

@HannesDyballa based on our latest conversation around cardinality, you mentioned that this is not a bigger concern that you had. Does that change anything about your statement?

We can just always export the GVK of the CRD, which gets exported, which would lead to a higher metric cardinality. I would be against this.

If cardinality is not an issue, I would like to go for B, especially since I know attempted to solve #145 with #253

[HannesDyballa]

@MichaelSp
I've actually changed my opinion on this. As I mentioned, I have experience with exporting uid and similar fields, and I didn't run into cardinality issues when using document storage. Cardinality would be a concern with a metric store, but I think GVK is perfectly acceptable here — so I'm in favor of exporting them. Option B is fine by me.