Add http.connection.protocol_error_code to connection duration metric

[JamesNK]

Area(s)

No response

Is your change request related to a problem? Please describe.

HTTP/2 and HTTP/3 define protocol error codes that are used when ending a HTTP connection.

• HTTP/1 - n/a
• HTTP/2 - Error codes: https://datatracker.ietf.org/doc/html/rfc9113#section-7
• HTTP/3 - Error codes: https://datatracker.ietf.org/doc/html/rfc9114#section-8.1

These codes are often - but not always - sent over the wire when a HTTP connection is ending gracefully or with an error. They can have useful information that explains why a connection was closed. They're basically the connection version of HTTP status code.

Describe the solution you'd like

Add a tag to client/server HTTP connection duration metrics that has this value.

Value would be an unsigned integer. HTTP/2 value can be up to 32 bits and HTTP/3 value can be up to 64 bits. To support both values, the tag definition should say its value in an unsigned 64 bit integer.

Although HTTP/2 and HTTP/3 have predefined values for the code, I think it should be a number like the HTTP status code. In it's possible to send an error code that isn't predefined, although it's not recommended.

The tags is omitted if the value is NO_ERROR (http/2) or H3_NO_ERROR (http/3)

Describe alternatives you've considered

The value could be put in error.type. I prefer having a different tag value because the server or client might want to supply the internal error reason in the error.type field, while it is still useful to know the protocol error code value that was sent to the peer.

Additional context

No response

[lmolkova]

Having a domain-specific attribute along with error.type would be right by design:

semantic-conventions/docs/attributes-registry/error.md

Lines 31 to 35 in cde003c

	If a specific domain defines its own set of error identifiers (such as HTTP or gRPC status codes),
	it's RECOMMENDED to:
	- Use a domain-specific attribute
	- Set `error.type` to capture all errors, regardless of whether they are defined within the domain-specific set or not.

The only suggestion I have is to call it http.connection.protocol.error_code (in case there will be more things in protocol) or http.protocol.error_code (for brevity and because these errors codes seem to apply to streams as well as connections).