[Monitor OpenTelemetry] Update Success/Failure Status Codes for Standard Metrics

[JacksonWeber]

Packages impacted by this PR

@azure/monitor-opentelemetry

Issues associated with this PR

Fixes #29398

Describe the problem that is addressed by this PR

Success/failure on standard metrics collection for dependencies and requests should follow the spec:
< 400 is success

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?

Are there test cases added in this PR? (If not, why?)

Updated test cases that already use the dividing line between success/failure (status code 400)

Checklists

• Added impacted package name to the issue description
• Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
• Added a changelog (if necessary)

[azure-sdk]

API change check

API changes are not detected in this pull request.

[harsimar]

I'm not too familiar with the spec, but why is <500 considered success for requests?

[JacksonWeber]

I'm not too familiar with the spec, but why is <500 considered success for requests?

HTTP status code 400s represent client errors, so my understanding of the logic behind the standard metrics spec on this is that because it's up to whoever is making the request to fix the issue, it's not a "failure" on the monitored application's side, but the requester's.
I've included a link to the relevant spec as well: https://github.com/aep-health-and-standards/Telemetry-Collection-Spec/blob/main/OpenTelemetry/metrics/ApplicationInsightsStandardMetrics.md#custom-dimensions

[JacksonWeber]

I'm not too familiar with the spec, but why is <500 considered success for requests?

HTTP status code 400s represent client errors, so my understanding of the logic behind the standard metrics spec on this is that because it's up to whoever is making the request to fix the issue, it's not a "failure" on the monitored application's side, but the requester's. I've included a link to the relevant spec as well: https://github.com/aep-health-and-standards/Telemetry-Collection-Spec/blob/main/OpenTelemetry/metrics/ApplicationInsightsStandardMetrics.md#custom-dimensions

Looks like this is an issue with the spec and disagrees with the common schema as well as being out of sync with all languages (except Java). Working on getting this resolved and made a spec update PR. Thank you for the review!

[hectorhdzg]

LGTM