Consolidate HTTP span data conventions with OpenTelemetry

[sl0thentr0py]

in preparation for some of our new performance UIs we're consolidating span data keys with OpenTelemetry with a new Span::DataConventions module.

This PR handles the HTTP spans.

see getsentry/team-sdks#20

[codecov]

Codecov Report

Patch coverage: 69.23% and project coverage change: -0.01% ⚠️

Comparison is base (86dfaea) 83.25% compared to head (fd17ccf) 83.25%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2093      +/-   ##
==========================================
- Coverage   83.25%   83.25%   -0.01%     
==========================================
  Files         119      119              
  Lines        5674     5679       +5     
==========================================
+ Hits         4724     4728       +4     
- Misses        950      951       +1     

Files Changed	Coverage Δ
sentry-ruby/lib/sentry/net/http.rb	29.78% <0.00%> (ø)
...rails/tracing/action_controller_subscriber_spec.rb	100.00% <100.00%> (ø)
sentry-rails/spec/sentry/rails/tracing_spec.rb	99.42% <100.00%> (ø)
sentry-ruby/lib/sentry/span.rb	87.95% <100.00%> (+0.77%)	⬆️

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[antonpirker]

lgtm

[st0012]

When we did a span name change in #1923, some users reported that it "broke" their filtering logic and resulted in higher-than-expected usages. Since status code could be a common method for filtering, I'm a bit concerned that similar issue could happen again. Should we still set status_code so users don't get breaking change in a minor version upgrade?

[szokeasaurusrex]

Looks good!

[sl0thentr0py]

@st0012 good point, but this is data whereas those were ops, I think it's fine to clean this up without consequences. The span status is still the same and that's what I'd recommend for filtering just in case.