Change SpanStatusExtractor to use a builder that can set status description

[HaloFour]

Currently the SpanStatusExtractor can only extract a StatusCode from the response and any error and never sets an appropriate description for the status of the span. This change adds a method to the SpanStatusExtractor to use a helper interface SpanStatusBuilder which delegates the setStatus methods to the underlying Span so that the extractor may set the status code and description.

[HaloFour]

I assume that we don't want to take breaking changes to the instrumenter interfaces, so we either need to break the new functionality into a new interface, or munge it into the existing one so that existing implementations (including lambdas) continue to work.

I also did not touch the HttpSpanStatusExtractor or GrpcSpanStatusExtractor implementations in this pass.

[trask]

I assume that we don't want to take breaking changes to the instrumenter interfaces

instrumentation-api has not been declared stable yet (though getting close), so we can (and should) make breaking changes if it makes for a better api

[HaloFour]

@trask

instrumentation-api has not been declared stable yet (though getting close), so we can (and should) make breaking changes if it makes for a better api

Good to know, that will make this much cleaner.

[HaloFour]

Updated AbstractHttpClientTest may be more involved since the status description may be different for each instrumented library. I've opened another PR which adds a new assertion method hasStatusSatisfying which would allow the tests to more flexibly test the status of the span.

Just realized that SpanDataAssert also has a generic satisfies method which will enable asserting the status with more flexibility.

[trask]

I'm unclear about this part of the spec:

When the status is set to Error by Instrumentation Libraries, the Description SHOULD be documented and predictable.

and whether an exception message is considered "predictable"

[HaloFour]

I think that statement makes sense for error conditions as interpreted by the instrumentation, e.g. a failing status code or the like. I can see where exceptions might be a bit murkier, but as long as the exception is being recorded as an event perhaps having it also be the description isn't as necessary (although I guess technically an exception event doesn't need to be the reason that the span status is "Error" either).

I can certainly unwind the rest of the changes here so the exception message is not the description. Would certainly make it easier to not have to deal with all of the exceptions that it broke. 😄

[HaloFour]

I've reverted setting the error message as the description by default, that's something we can revisit. This PR will instead only provide the SpanStatusExtractor that is capable of setting that description.

[mateuszrzeszutek]

Thanks!
The exception message can contain pretty much anything (see #3039 for a really bad example), I too wouldn't call it "predictable". And we're already capturing it as the exception.message attribute, adding the same string as status description would be duplicating the data a little bit.

[mateuszrzeszutek]

Thanks!
LGTM 👍

[mateuszrzeszutek]

Nit: could be

      if (!status.isOk()) {
        spanStatusBuilder.setStatus(StatusCode.ERROR);
      }

[trask]

thx!

[mateuszrzeszutek]

Hey @HaloFour
Looks like this PR already got all approvals it needed -- do you want to make it ready for review?

[trask]

thx @HaloFour!