OTLP traces export errors use a consistent error message prefix

[jmacd]

When a user configures both a tracing SDK and metrics SDK the, existing error-handling and logging mechanism do not indicate whether it is a tracing or a metrics failure. For SDKs and vendors that route metrics and traces to different services, it is important to indicate which of the two paths is experiencing problems.

Part of #3513.

[codecov]

Codecov Report

Merging #3516 (8be26f1) into main (af3db6e) will increase coverage by 0.2%.
The diff coverage is 85.7%.

❗ Current head 8be26f1 differs from pull request most recent head 91e7554. Consider uploading reports for the commit 91e7554 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3516     +/-   ##
=======================================
+ Coverage   79.4%   79.7%   +0.2%     
=======================================
  Files        170     171      +1     
  Lines      12654   12673     +19     
=======================================
+ Hits       10056   10101     +45     
+ Misses      2388    2359     -29     
- Partials     210     213      +3     

Impacted Files	Coverage Δ
exporters/otlp/otlptrace/exporter.go	66.6% <80.0%> (+66.6%)	⬆️
exporters/otlp/internal/wrappederror.go	86.6% <86.6%> (ø)
exporters/otlp/otlptrace/otlptracehttp/client.go	77.5% <100.0%> (ø)
sdk/trace/batch_span_processor.go	80.2% <0.0%> (-1.8%)	⬇️

[MrAlias]

Please fix the lint issues and add a changelog entry.

[MrAlias]

This seems like a lot of code to add to ensure the two client error messages have a prefix. Why not just add the prefix to the client response?

[dashpole]

Overall, I think adding information to the the error message is helpful, and worth the extra branch.

[jmacd]

This seems like a lot of code to add to ensure the two client error messages have a prefix.

This point is well taken. This PR and #3515 can be done better and I will give it a try. My biggest concern among these three is actually #3514, which conceals the gRPC or HTTP error message when the final error was retryable. I'll close this and #3515 for now and reopen when it's in better shape.

Why not just add the prefix to the client response?

There are cases where the retry mechanism returns a local error that would not be prefixed, that's what led me to this in the first place. When you get the full gRPC error message you're likely to have enough context to determine whether it's a tracing SDK problem or a metrics SDK problem.

[jmacd]

I changed this PR to use a wrapped error and restored the old tests w/ a call to errors.Unwrap(), since if you want to use os.IsTimeout() or the grpc/status package you need to have the exact error. This makes it a slight change for callers, but I've updated all the tests and the changelog to indicate that errors.Unwrap is needed.

[jmacd]

If the approach taken here is acceptable, I would restore #3515 with the same (using the new internal wrappedExportError type from this PR) for metrics. Thanks.