http span and error.type

Spec https://opentelemetry.io/docs/specs/semconv/http/http-spans/ says

[5] error.type: If the request fails with an error before response status code was sent or received, error.type SHOULD be set to exception type (its fully-qualified class name, if applicable) or a component-specific low cardinality error identifier.
If response status code was sent or received and status indicates an error according to HTTP span status definition, error.type SHOULD be set to the status code number (represented as a string), an exception type (if thrown) or a component-specific error identifier.
The error.type value SHOULD be predictable and SHOULD have low cardinality. Instrumentations SHOULD document the list of errors they report.
The cardinality of error.type within one instrumentation library SHOULD be low, but telemetry consumers that aggregate data from multiple instrumentation libraries and applications should be prepared for error.type to have high cardinality at query time, when no additional filters are applied.

Relates to this place:
https://github.com/labstack/echo-opentelemetry/blob/a9468a6839c299cdee00c2c86eab31418a86f3b9/otel.go#L217-L224

Start with otel.go lines 217-224 and compare the current handling with the linked OpenTelemetry HTTP spans specification. Determine how error.type should be represented before and after a response status code; the work is done when this instrumentation follows the cited rules with predictable, low-cardinality values.