refactor(instr-connect): use exported strings for attributes

[david-luna]

Which problem is this PR solving?

• Updates Update usage of semantic conventions to new exported strings #2025

Short description of the changes

• Update @opentelemetry/semantic-conventions to ^1.22
• Replace SemanticAttributes.* with exported strings SEMATTRS_*
• Update README with new semantic convention package version and key

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.47%. Comparing base (dfb2dff) to head (4bb098a).
Report is 104 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2154      +/-   ##
==========================================
- Coverage   90.97%   90.47%   -0.51%     
==========================================
  Files         146      148       +2     
  Lines        7492     7590      +98     
  Branches     1502     1591      +89     
==========================================
+ Hits         6816     6867      +51     
- Misses        676      723      +47     

Files	Coverage Δ
...try-instrumentation-connect/src/instrumentation.ts	98.98% <100.00%> (-0.03%)	⬇️

... and 35 files with indirect coverage changes

[blumamir]

LGTM

Left a general question about the current/future goal for the non-semantic attributes

[blumamir]

I wonder if it can be helpful to also enumerate the other, non-spec-compliant attributes that are emitted by this instrumentation, as a reference for users and for them to know what to expect when using this instrumentation.

There seems to be 2 custom attributes at the moment:

export enum AttributeNames {
  CONNECT_TYPE = 'connect.type',
  CONNECT_NAME = 'connect.name',
}

Do you think eventually we will need to either remove them or add them to the specs? Or eventually, each instrumentation is allowed to record extra attributes for which we also need some sort of documentation and stability guarantee?

[pichlermarc]

Do you think eventually we will need to either remove them or add them to the specs?

I'm not sure. I reached out to @joaopgrassi (semconv maintainer) to ask what the general rules are for instrumentations that emit non-semconv telemetry. It'll be brought up in the semconv SIG meeting today 🙂

[blumamir]

Thanks @pichlermarc and @joaopgrassi .

Any update on this issue?

I think it should not block the current PR. The non-semantic attributes can also be removed / added to docs in followup PRs once we get more guidelines.

[JamieDanielson]

True we can probably open this as a new issue to look into and follow-up on.

[JamieDanielson]

I've created #2170 for follow-up