Open Telemetry: Adds open telemetry based versioning

[sourabh1007]

Description

Introducing versioning for open telemetry attributes, to make we are always backward compatible.

database => Have latest stable/experimental attributes, In our case it would otel supported attributes.
database/dup => have latest and old stable/experimental attributes, in our case it would be otel supported attributes and appinsights supported attributes, it is normal to see same value in 2 different attribute keys.
default => old attributes. in our case, it is Appinsights Compatible attributes
appinsightssdk => reserved for future, when we GA open telemetry attributes, then by default open telemetry compatible attributes will be emitted but customer would be able to get backward compatibility, if they set this env variable. It is not used yet.

Other minor changes,

1. Fix connection mode casing

{
              ConnectionMode.Direct => "direct",
              ConnectionMode.Gateway => "gateway",
              _ => throw new NotImplementedException()
          };

2. rename db.cosmosdb.item_count => db.cosmosdb.row_count

Code changes Overview

1. Introduced, TracesStabilityFactory.cs : Responsible to take care of version based attributes.
2. Updated Baseline Tests to have old and new both attributes in contract file.

Type of change

Please delete options that are not relevant.

• [] Bug fix (non-breaking change which fixes an issue)
• [] New feature (non-breaking change which adds functionality)
• [] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [] This change requires a documentation update

[FabianMeiswinkel]

I get what you want to do here - but why not use subclasses. Like have a CosmosTracer base class (withonly private ctor) and a static factory methode that will create the right subclass (each implementing an abstract populateXXX method). That avoids the need to change signatures when a third version is added and seems more readbale/intuitive than passing around actions?

[FabianMeiswinkel]

I still can't say i understasnd/like the version identifiers. That put aside - the docs should refer to a place where the difference (schema of events) is clearly spelled out for the different versions. Can be a separate md file just referenced here.

[sourabh1007]

I agree with you, and I must admit, I'm not a fan of this versioning identifier either. It's somewhat difficult to understand, but we’re aligning with the OpenTelemetry community's decision to maintain consistency across products.

do you mean, maintaining a md file with an information about, list of attributes getting generated for each stability modes?

[FabianMeiswinkel]

LGTM overall but left two comments.