[PROPOSAL] HTTP Client Span Name Processor

[stevejgordon]

Currnetly HTTP client span names are very limited, using only the HTTP method. This makes it less useful in the default UIs, such as trace waterfall, to know where requests are being sent. This is being discussed in a few places, both internally and with the OTel WG in Slack. There may be an open to a proposal that the hostname and perhaps port are encoded in the conventions, but there are no guarantees. I'll open an issue to discuss that further. Another possibility is changes in Kibana and the APM UIs to expose the attributes in the trace waterfall labels. A more immediate option would be to add a processor in the OTel distro to rename HTTP client spans following our opinionated approach. This would have the impact of matching more closely what the APM agent does today and making the UI more useful, but would diverge from the conventions. This might be something that needs to be opt-in or opt-out vs. a fixed behaviour we apply. Some customers may not want us to deviate from the semantic conventions even if it improves the UX.

This could initially focus on HTTP client spans, but perhaps we'd want to make it more extensible for other future scenarios. We also need to consider the auto-instrumentation story.