Http server semconv span stable

[dyladan]

Updates semconv to 1.27 for server spans.

Metrics to be done in followup.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.39%. Comparing base (f8ab559) to head (1054a44).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4978   +/-   ##
=======================================
  Coverage   93.39%   93.39%           
=======================================
  Files          46       46           
  Lines         712      712           
  Branches      120      120           
=======================================
  Hits          665      665           
  Misses         47       47           

[JamieDanielson]

Thank you for working on this!

[JamieDanielson]

I'm not sure how best to update without making this big PR even bigger, but the section with the table of attributes will need to be updated in some way (starting on line 114 that still references Server Spans). It may be worth having two tables - 1 representing old, 1 representing new. I'm happy to help craft that table in a separate issue and we can issue a follow-up PR. I would recommend at least a small change to that section though along the lines of "These are the attributes in the default behavior using only experimental attributes".

[dyladan]

I left the old table as-is for now. The new semconv is documented already in the semconv repo. When we remove this fallback the old table will be removed entirely. Would that be sufficient or do you think we need a table here as well?

[JamieDanielson]

I've gotten a lot of requests for showing what attributes are included in instrumentation, especially as different instrumentations (and languages) are in different versions. Folks also ask about other attributes (non-semconv) in different instrumentations, e.g. express.name, though that's less relevant for http here. The semconv might be in the semconv repo but it doesn't specify what we include, and may not be easily navigable by end users. Ideally we autogenerate a list of attributes vs handcrafting a table though, but with the table already there we may as well use it.

[pichlermarc]

thanks for pointing this out - I also had a quick look and it does not seem like there's a easy way to do it 😞
I think using the library is justified.

I think we may want to use the new ATTR_ imports even for old semconv. So the ATTR_ stable attributes should still get imported as-is, but the ATTR_ incubating/experimental attributes should be used and imported from semantic-conventions/incubating.