chore: adding instrumentation for connect

[obecny]

Which problem is this PR solving?

• Fixes New Instrumentation - connect #550

Short description of the changes

• Ads auto instrumentation for connect

[codecov]

Codecov Report

Merging #588 (ba64963) into main (e95221b) will increase coverage by 0.01%.
The diff coverage is n/a.

❗ Current head ba64963 differs from pull request most recent head 70c61ce. Consider uploading reports for the commit 70c61ce to get more accurate results

@@            Coverage Diff             @@
##             main     #588      +/-   ##
==========================================
+ Coverage   94.96%   94.98%   +0.01%     
==========================================
  Files         200      199       -1     
  Lines       11787    11849      +62     
  Branches     1122     1108      -14     
==========================================
+ Hits        11194    11255      +61     
- Misses        593      594       +1     

Impacted Files	Coverage Δ
...lemetry-instrumentation-document-load/src/utils.ts
...entation-document-load/src/enums/AttributeNames.ts
...metry-instrumentation-document-load/src/version.ts
...strumentation-document-load/src/instrumentation.ts
...trumentation-document-load/src/enums/EventNames.ts
...strumentation-connect/test/instrumentation.test.ts	98.97% <0.00%> (ø)
...entelemetry-instrumentation-connect/src/version.ts	100.00% <0.00%> (ø)
...try-instrumentation-connect/src/instrumentation.ts	98.71% <0.00%> (ø)
...nstrumentation-connect/src/enums/AttributeNames.ts	100.00% <0.00%> (ø)

[vmarchaud]

lgtm, just need to fix tests

[rauno56]

Few nits, otherwise beautifully crafted! 👍

[rauno56]

@obecny, see #588 (comment)
There's an example of that in koa tests.

[dyladan]

What should we do about the component_owners.yml in the case maintainers add the instrumentation? Is it ok to have an unowned instr or should you own it?

[vmarchaud]

What should we do about the component_owners.yml in the case maintainers add the instrumentation? Is it ok to have an unowned instr or should you own it?

Well i think we should add them for every instrumentation in case there is a change in maintainer ? Specially since its one of us that have wrote it, it will force us to switch ownership when stepping down.
However it can be done later on in another PR, we need to decide who own each of the instrumentations anyway

[dyladan]

What should we do about the component_owners.yml in the case maintainers add the instrumentation? Is it ok to have an unowned instr or should you own it?

Well i think we should add them for every instrumentation in case there is a change in maintainer ? Specially since its one of us that have wrote it, it will force us to switch ownership when stepping down.
However it can be done later on in another PR, we need to decide who own each of the instrumentations anyway

Stepping down as maintainer wouldn't mean stepping down as component owner I think.

[vmarchaud]

Stepping down as maintainer wouldn't mean stepping down as component owner I think

Not necessarely i agree, however if a maintainer don't have the time anymore to work on otel i suppose he would not have the time to review PRs about components he owns (in the case of a step down because of lack of time of course).