internal/shared/semconv: set http.route from Request.Pattern

[axw]

If Request.Pattern is set (e.g. by net/http.ServeMux), then use it for setting the http.route attribute on server request spans.

Related to #6193

(But does not close that, since according to https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name we SHOULD use http.route in the span name. I'm leaving that for another day.)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.6%. Comparing base (b6f6e0e) to head (4ff9fcc).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #6905     +/-   ##
=======================================
+ Coverage   75.5%   75.6%   +0.1%     
=======================================
  Files        207     207             
  Lines      19319   19354     +35     
=======================================
+ Hits       14598   14646     +48     
+ Misses      4285    4273     -12     
+ Partials     436     435      -1     

Files with missing lines	Coverage Δ
...o-restful/otelrestful/internal/semconv/httpconv.go	86.7% <100.0%> (+0.7%)	⬆️
...gin-gonic/gin/otelgin/internal/semconv/httpconv.go	86.7% <100.0%> (+0.7%)	⬆️
...m/gorilla/mux/otelmux/internal/semconv/httpconv.go	86.7% <100.0%> (+0.7%)	⬆️
...tptrace/otelhttptrace/internal/semconv/httpconv.go	86.7% <100.0%> (+0.7%)	⬆️
...ion/net/http/otelhttp/internal/semconv/httpconv.go	86.7% <100.0%> (+0.7%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dmathieu]

semconvutil is for the 1.20.0 semantic conventions. It will disappear on the next release.
Don't you want to add that to internal/shared/semconv instead?

[axw]

@dmathieu sounds like it - I wasn't aware of that :) I'll have a look tomorrow.

[axw]

@dmathieu updated, I hope I'm doing the right thing now.

[akats7]

Looks like most of the middleware's are setting this value with their internal equivalent, in which case the order that the attributes are passed in the middleware matters, looks fine but just something to be aware of.

[axw]

Thanks for pointing that out @akats7. I've checked all the in-tree instrumentation and the instrumentation-specific route attribute will take precedence.

[dmathieu]

Not for this PR, but we should analyze the frameworks that have those instrumentation-specific route, and see if they could be replace to setting the request's Pattern.