fix: e2e test checks label value by name and not by index

[JorTurFer]

As we don't check otel metrics directly but exported via Prometheus in collector, we are affected by posible changes in how the labels are generated, for example, with the collector v1.128.0, the metrics is:

keda_cloudeventsource_events_emitted_count_total{
cloudEventSource="opentelemetry-metrics-test-ce",
eventsink="http",
job="unknown_service:keda",
namespace="opentelemetry-metrics-test-ns",
otel_scope_name="keda-open-telemetry-metrics",
otel_scope_schema_url="",
otel_scope_version="",
state="emitted"
} 1

And the same metric from the collector v1.127.0 is:

keda_cloudeventsource_events_emitted_count_total{
cloudEventSource="opentelemetry-metrics-test-ce",
eventsink="http",
job="unknown_service:keda",
namespace="opentelemetry-metrics-test-ns",
state="emitted"
} 1

This PR changes the search to get the value by key and not by position to be resilient to changes in the labels because of metric tranformations under the scope of the test

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)

[JorTurFer]

/run-e2e sequential
Update: You can check the progress here

[JorTurFer]

/run-e2e sequential
Update: You can check the progress here

[JorTurFer]

/run-e2e sequential
Update: You can check the progress here

[dttung2905]

I think it is a cleaner way of accessing the Prom label value. The only downside is a slight degrade in performance. For each of the label, we are looping through the whole arr which is O(n) instead of the current way of using index with O(1) time complexity. I personally think it is acceptable to trade performance for readability & maintainability in this case.
If you have a better way, let me know too 😃

[JorTurFer]

I think it is a cleaner way of accessing the Prom label value. The only downside is a slight degrade in performance. For each of the label, we are looping through the whole arr which is O(n) instead of the current way of using index with O(1) time complexity. I personally think it is acceptable to trade performance for readability & maintainability in this case. If you have a better way, let me know too 😃

yeah, I did this change for e2e because it's just a single place to use and actually, the old approach failed on upstream changes, but definitively it'd not be good for production :)