Handle HTTP 304s when setting span status

[akshayjshah]

If the RPC is using the Connect protocol and returns a not modified
error, we shouldn't set the span status to error. Follow-up to #120.

[joshcarp]

This also brings up the problem that ~3 months ago there was a breaking change to how grpc span statuses are set in the opentelemetry specification: open-telemetry/opentelemetry-specification#3333

Table as follows:

gRPC Status Code	SpanKind.SERVER Span Status	SpanKind.CLIENT Span Status
OK	unset	unset
CANCELLED	unset	Error
UNKNOWN	Error	Error
INVALID_ARGUMENT	unset	Error
DEADLINE_EXCEEDED	Error	Error
NOT_FOUND	unset	Error
ALREADY_EXISTS	unset	Error
PERMISSION_DENIED	unset	Error
RESOURCE_EXHAUSTED	unset	Error
FAILED_PRECONDITION	unset	Error
ABORTED	unset	Error
OUT_OF_RANGE	unset	Error
UNIMPLEMENTED	Error	Error
INTERNAL	Error	Error
UNAVAILABLE	Error	Error
DATA_LOSS	Error	Error
UNAUTHENTICATED	unset	Error

[jhump]

@akshayjshah, I pushed a commit with a test.

@joshcarp, maybe file that as a separate issue? Maybe we can address that in subsequent PR -- and maybe even subsequent release? Ideally, we'd get this fix out soon since the current release is causing unnecessary alerts in the BSR.

[jhump]

LGTM. You may want to take a look at my test and revise if you see a better way to do this (or are unhappy with the buf lint exclusions I added).

[akshayjshah]

Thanks for the test case, @jhump! I pushed a small change to make the Ping method idempotent rather than introducing a new one, but the test logic itself looks great.