use semantic convention APIs for opentelemetry

[aleqi200]

Motivation:

Today the tags are manually handcrafted with strings, if the opentelemetry api changes, the tags will be outdated, using the instrumenter available from the io.opentelemetry.instrumentation:opentelemetry-instrumentation-api-semconv we can make it all dynamic based on the specification without understanding the specification and its tags.

Result:

API will become more stable and evolve easier together with opentelemetry, no more handcrafted strings and the conventions will be driven by the instrumentation API.

[aleqi200]

The tags are now showing the following:

The tags are driven by the semantic conventions available in the API.

Tag	Value
http.method	POST
http.request.header.transaction_id	[ "1234" ]
http.request.header.x_shield_req_id	[ "1234-asdf" ]
http.request_content_length	87
http.response_content_length	36
http.route	/job
http.status_code	200
http.target	/job
internal.span.format	proto
net.host.name	localhost
net.host.port	8082
net.protocol.name	http
net.protocol.version	1.1
otel.library.name	io.servicetalk
otel.status_code	OK
span.kind	server
thread.id	24
thread.name	servicetalk-global-io-executor-1-3
user_agent.original	curl/7.88.1

This will allow capture of request/response headers like above http.request.header.transaction_id.

[aleqi200]

Metrics will be available for spans as well.
The following metrics were captured using the updated API with opentelemetry and prometheus:

[daschl]

I wonder if we should rename this to OpenTelemetryHttpServiceFilter to have proper alignment with the client?

[aleqi200]

Renaming will break clients who are already using it.

[idelpivnitskiy]

We can introduce new names and deprecate all names (not in this PR, in a follow-up)

[aleqi200]

ok, will do in a follow up PR

[daschl]

I wonder if we should rename this to OpenTelemetryHttpClientFilter to have proper alignment with the service?

[aleqi200]

That's too late. We cannot break the contract with clients, renaming will cause a breaking change.

[idelpivnitskiy]

Not in this PR, but in a follow up it will be nice to rename it to OpenTelemetryHttpRequesterFilter to be consistent with all other filters. We use "requester" on the client-side because all clients and connections implement HttpRequester interface.

For backward compatibility, we can deprecate current OpenTelemetryHttpRequestFilter and link to OpenTelemetryHttpRequesterFilter as a replacement.

[idelpivnitskiy]

We can introduce new names and deprecate all names (not in this PR, in a follow-up)

[idelpivnitskiy]

Not in this PR, but in a follow up it will be nice to rename it to OpenTelemetryHttpRequesterFilter to be consistent with all other filters. We use "requester" on the client-side because all clients and connections implement HttpRequester interface.

For backward compatibility, we can deprecate current OpenTelemetryHttpRequestFilter and link to OpenTelemetryHttpRequesterFilter as a replacement.

[idelpivnitskiy]

Pushed 2 commits to address the last comments I have below:

[aleqi200]

the changes look good. I made a test and it looks good.

[idelpivnitskiy]

Thank you!