adding otel attributes to config_telemetry

[patrickhuie19]

NONEVM-828

I considered 3 options while implementing this:

1. Make these fields defaults in the TOML. The static.Version field is set at build time, so its available to tests that test default TOML. From a user experience though, I may want to always set these fields, so user configurable does not seem like a perfect fit.
2. The current approach, which overrides the getter on ResourceAttributes after the general app config has been made
3. Set these values way higher in the stack for the consumers of beholder.Config. Most straightforward to read and reason about, but either introduces duplication when loops are spun up or pollutes a clean default initialization of a beholder client.

Requires

Supports

[github-actions]

AER Report: CI Core ran successfully ✅

aer_workflow , commit

AER Report: Operator UI CI

aer_workflow , commit , Breaking Changes GQL Check

1. Workflow failed to complete successfully:[Breaking Changes GQL Check]

Source of Error:

Run convictional/trigger-workflow-and-wwait@f69fa9eedd3c62a599220f4d5745230e237904be	2024-11-08T18:29:01.7269656Z Checking conclusion [failure]
Run convictional/trigger-workflow-and-wwait@f69fa9eedd3c62a599220f4d5745230e237904be	2024-11-08T18:29:01.7270734Z Checking status [completed]
Run convictional/trigger-workflow-and-wwait@f69fa9eedd3c62a599220f4d5745230e237904be	2024-11-08T18:29:01.7272187Z Conclusion is not success, it's [failure].
Run convictional/trigger-workflow-and-wwait@f69fa9eedd3c62a599220f4d5745230e237904be	2024-11-08T18:29:01.7273585Z Propagating failure to upstream job

Why: The triggered workflow did not complete successfully, resulting in a failure status. This failure was then propagated back to the upstream job, causing the entire run to fail.

Suggested fix: Investigate the logs of the downstream workflow (ID: 11747552668) to identify the specific cause of the failure and address the underlying issue.

[Atrax1]

LGTM