chore: update KSQL metrics context labels

[stevenpyzhang]

Description

• lower case the resource type
• adds the following configs to ksqlConfig when initializing KSQL for either headless or interactive mode so that all components get the same base set of labels

metrics.context.resource.kafka.cluster.id
metrics.context.resource.type
metrics.context.resource.cluster.id
metrics.context.resource.version
metrics.context.resource.commit.id

Testing done

Rechecking labels present in the staging URL for Druid

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[xiaodongdu]

if ksql.cluster.id and ksql.service.id are the same, why do we need both?

[stevenpyzhang]

we can remove RESOURCE_LABEL_KSQL_SERVICE_ID and just keep the cluster id label. The service id of a KSQL server is the only id for it so it essentially is the cluster id

[xiaodongdu]

RESOURCE_LABEL_CLUSTER_ID and RESOURCE_LABEL_KAFKA_CLUSTER_ID are the same. I would recommend to keep RESOURCE_LABEL_KSQL_SERVICE_ID which is more meaningful for KSQL.

[stevenpyzhang]

Oh I see, I was under the impression that the cluster id meant the ksql cluster id, not the kafka one. If that's the case, then I'll keep RESOURCE_LABEL_KSQL_SERVICE_ID

[xvrl]

@stevenpyzhang @xiaodongdu I think it makes more sense to keep ksql.cluster.id as the KSQL service ID, and ksql.kafka.cluster.id as the backing cluster id to align with the terminology we already use in RBAC https://docs.confluent.io/current/security/rbac/rbac-get-cluster-ids.html#ksqldb-example

We should fix the other components if they don't align.

[stevenpyzhang]

@xvrl I've updated the PR to match with this ^

[xiaodongdu]

Fix looks fine, one thing I'm not clear, metrics.context.resource.cluster.id and metrics.context.resource.service.id are both populated with service id, why do we need both?