Add semconv v1.24.0 to otelhttp

[MadVikingGod]

This change adds semantic convention v1.24.0 to otlehttp and the compatibility mode that was required in the v1.21.0 semantic convention.

Scope

This is the first in a series of patches to fully finish out this feature. The goal is to show how the environment variable can be supported and how it can be used.

What was excluded to aid in reviewability, all can be added after:

• Templating - Changes need to be made to each instrumentation to opt into the new methods.
• Client Instrumentation - This will follow a similar pattern to the HTTPServer interface and supplied by new types.
• Metrics Instrumentation - The Methods are in the interface but aren't used.

Benchmarks

A benchmark was added to aid in comparing. I've added the raw data to this gist.

First I wanted to make sure that this didn't introduce performance regressions to users using the default/old attributes:

benchstat bench-orig.txt bench-old.txt 
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/internal/semconv
cpu: AMD EPYC 7763 64-Core Processor                
                           │ bench-orig.txt │             bench-old.txt             │
                           │     sec/op     │    sec/op     vs base                 │
HTTPServerRequest-2            478.5n ± 19%   504.8n ± 22%       ~ (p=0.218 n=10)
HTTPServerRequestMetrics-2     279.9n ± 13%
geomean                        366.0n         504.8n        +5.51%                ¹
¹ benchmark set differs from baseline; geomeans may not be comparable

                           │ bench-orig.txt │            bench-old.txt            │
                           │      B/op      │    B/op     vs base                 │
HTTPServerRequest-2              644.0 ± 0%   644.0 ± 0%       ~ (p=1.000 n=10) ¹
HTTPServerRequestMetrics-2       388.0 ± 0%
geomean                          499.9        644.0       +0.00%                ²
¹ all samples are equal
² benchmark set differs from baseline; geomeans may not be comparable

                           │ bench-orig.txt │            bench-old.txt            │
                           │   allocs/op    │ allocs/op   vs base                 │
HTTPServerRequest-2              2.000 ± 0%   2.000 ± 0%       ~ (p=1.000 n=10) ¹
HTTPServerRequestMetrics-2       2.000 ± 0%
geomean                          2.000        2.000       +0.00%                ²
¹ all samples are equal
² benchmark set differs from baseline; geomeans may not be comparable

Next I wanted to make sure the new way of attributes were not significantly different. I assumed that http/dup will take more time, because it has to deal with twice as many attributes, but I wanted to allocations to stay the same.

benchstat bench-old.txt bench-new.txt bench-dup.txt
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/internal/semconv
cpu: AMD EPYC 7763 64-Core Processor                
                    │ bench-old.txt │         bench-new.txt          │            bench-dup.txt             │
                    │    sec/op     │    sec/op     vs base          │    sec/op     vs base                │
HTTPServerRequest-2    504.8n ± 22%   457.1n ± 12%  ~ (p=0.075 n=10)   807.6n ± 16%  +59.97% (p=0.000 n=10)

                    │ bench-old.txt │           bench-new.txt           │            bench-dup.txt             │
                    │     B/op      │    B/op     vs base               │    B/op      vs base                 │
HTTPServerRequest-2      644.0 ± 0%   708.0 ± 0%  +9.94% (p=0.000 n=10)   1540.0 ± 0%  +139.13% (p=0.000 n=10)

                    │ bench-old.txt │         bench-new.txt          │         bench-dup.txt          │
                    │   allocs/op   │ allocs/op   vs base            │ allocs/op   vs base            │
HTTPServerRequest-2      2.000 ± 0%   2.000 ± 0%  ~ (p=1.000 n=10) ¹   2.000 ± 0%  ~ (p=1.000 n=10) ¹
¹ all samples are equal

Testing

I utilized the semantic convention checker, from PR4701, but modified, set to http/dup, and used two configs one for v1.20 and v1.24. I can put this onto a branch if someone would like to recreate this work.

[codecov]

Codecov Report

Attention: Patch coverage is 86.38132% with 35 lines in your changes are missing coverage. Please review.

Project coverage is 61.8%. Comparing base (f3ba8c2) to head (30adb7e).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #5092     +/-   ##
=======================================
+ Coverage   61.2%   61.8%   +0.5%     
=======================================
  Files        185     190      +5     
  Lines      11207   11444    +237     
=======================================
+ Hits        6865    7076    +211     
- Misses      4142    4163     +21     
- Partials     200     205      +5     

Files	Coverage Δ
instrumentation/net/http/otelhttp/handler.go	91.6% <100.0%> (+4.4%)	⬆️
...ntation/net/http/otelhttp/internal/semconv/util.go	100.0% <100.0%> (ø)
...tion/net/http/otelhttp/internal/semconv/v1.20.0.go	100.0% <100.0%> (ø)
...entation/net/http/otelhttp/internal/semconv/env.go	88.8% <88.8%> (ø)
...tion/net/http/otelhttp/internal/semconv/v1.24.0.go	80.5% <80.5%> (ø)
...entation/net/http/otelhttp/internal/semconv/dup.go	81.2% <81.2%> (ø)

... and 1 file with indirect coverage changes

[dashpole]

when using both, which metric names do they get, or are the metric names the same?

[MadVikingGod]

This could go one of two ways:

1. Because the Metrics Semconv, and our package is not stable we just eat this breaking change. Then in the both we follow whatever we set for the instrumentation's Semantic Version (which should be 1.24.0 for both).
2. We add an abstraction back in that makes the creation of the metrics (from the MeterProvider) and what names are used as part of this new package. This is basically what I've tried to remove in this package as much as possible.

I would very much not want to build an abstraction on this code path; it's what made it so hard to upgrade and will eventually leave us with an API surface that no longer makes sense, e.g., HTTPFlavor was something we eventually had to drop.

didn't mean to approve

[carrbs]

nit: :s/methos/method