Open Telemetry: Fixes attribute name following otel convention

[sourabh1007]

Description

What is the change?

db.cosmosdb.operation_type --> removed (moved to classic sdk support)
db.cosmosdb.machine_id --> removed (moved to classic sdk support)
db.cosmosdb.client_id --> db.cosmosdb.client.id it will remain same (aligns with OTel messaging conventions)
db.cosmosdb.request_content_length --> db.cosmosdb.request.content_length it will remain same (aligns with OTel HTTP conventions)
db.cosmosdb.response_content_length --> db.cosmosdb.request.content_length it will remain same (aligns with OTel HTTP conventions)
db.cosmosdb.status_code --> db.response.status_code (moved db.cosmosdb.status_code to classic sdk support)
db.cosmosdb.consistency_level -> added
db.cosmosdb.request_content_length_bytes -> added for classic sdk support

Why?

Lot of discussions are going on with Azure Core and Open Telemetry Community teams. As part of that discussion, we are making these changes as our goal is to be Open Telemetry and Azure compliant,

Type of change

Please delete options that are not relevant.

• [] Bug fix (non-breaking change which fixes an issue)

Closing issues

To automatically close an issue: closes #4553

[github-actions]

All good!

[philipthomas-MSFT]

nit: Just some encouragement to provide more explicit context on why these changes are important.

[lmolkova]

The proposal looks good to me!

There is a caveat that we can't update OTel semantic conventions with this:

db.cosmosdb.client_id --> db.cosmosdb.client.id (aligns with OTel messaging conventions)
db.cosmosdb.request_content_length --> db.request.content_length (aligns with OTel HTTP conventions)
db.cosmosdb.response_content_length --> db.response.content_length (aligns with OTel HTTP conventions)

because of some tooling/process issues. I'm working on addressing them, but in the meantime we'll need to either hold back this part of the change or be inconsistent with what's documented in the OTel today until tooling problems are resolved.

[kirankumarkolli]

The proposal looks good to me!

There is a caveat that we can't update OTel semantic conventions with this:

db.cosmosdb.client_id --> db.cosmosdb.client.id (aligns with OTel messaging conventions)
db.cosmosdb.request_content_length --> db.request.content_length (aligns with OTel HTTP conventions)
db.cosmosdb.response_content_length --> db.response.content_length (aligns with OTel HTTP conventions)

because of some tooling/process issues. I'm working on addressing them, but in the meantime we'll need to either hold back this part of the change or be inconsistent with what's documented in the OTel today until tooling problems are resolved.

What's the timeline for tooling readiness?

[sourabh1007]

The proposal looks good to me!
There is a caveat that we can't update OTel semantic conventions with this:

db.cosmosdb.client_id --> db.cosmosdb.client.id (aligns with OTel messaging conventions)
db.cosmosdb.request_content_length --> db.request.content_length (aligns with OTel HTTP conventions)
db.cosmosdb.response_content_length --> db.response.content_length (aligns with OTel HTTP conventions)

because of some tooling/process issues. I'm working on addressing them, but in the meantime we'll need to either hold back this part of the change or be inconsistent with what's documented in the OTel today until tooling problems are resolved.

What's the timeline for tooling readiness?

We discussed this with @lmolkova and estimated that tool readiness would take about one month. However, we agreed it's not a high-priority task, as we're comfortable with the current naming, provided the OpenTelemetry community accepts it. We would, however, be hesitant to make changes in the future.