add tracing APIs and instrumentation

[lucix-aws]

Tracing component of #470

• misc
  • adds Java-esque abstract Middleware codegen classes
  • adds the most common stdlib functions we use directly into Writer's context so they can be referenced without having to inject a symbol (e.g. fmt.Sprintf)
• Adds smithy-go/tracing APIs
• New module: github.com/aws/smithy-go/tracing/smithy-otel-tracing adapts an OTEL SDK TracerProvider for use with Smithy clients
• Instrument clients operations with the following span hierarchy:
  • Initialize
  • BuildRequest
    • OperationSerializer
  • ResolveAuthScheme
  • GetIdentity
  • ResolveEndpoint
  • ComputePayloadSHA256
  • (note - everything from here down is part of the retry loop, but it is not instrumented that way here because all of the retry logic is SDK-side right now)
    • SignRequest
    • DoHTTPRequest
    • OperationDeserializer
• Adds the following Span attributes
  • rpc.method - name of the operation
  • rpc.service - sdkID of the service (or shape name if not present)
  • rpc.system - hardcoded to aws-api
  • Theoretically this would vary by client scope (e.g. non-AWS SDKs would set something different here). I've elected to defer allowing configuration of it for now since it's really just a string, if you disagree let's discuss
  • error.go.type - literal go type of an operation's error e.g. &smithy.GenericAPIError
  • error.go.error - results of Error() on an operation's error
  • error.api.fault - if error is a smithy API error, the fault type (client/server/unknown)
  • error.api.code - if error ", the error code
  • error.api.message - if error ", the error message
  • error - true if operation returned an error
  • http.proto - HTTP protocol version (as read from the response)
  • http.request.content_length - content length of serialized request body
  • http.request.method - HTTP method of serialized request
  • http.response.status_code - HTTP status code of raw response
  • http.response.content_length - content length of raw response body
  • operation.resolved_endpoint - the exact URL returned from endpoint resolution (including the scheme and any base path)
  • operation.auth.resolved_scheme_id - the auth scheme ID selected during resolution e.g. aws.auth#sigv4

[lucix-aws]

General comment for the spans:

1. Any reason why we picked the middlewares that we picked for when to start a child span? Retry makes a lot of sense, the other ones I suspect are the ones that we know can take longer but curious to hear your thoughts

Most of them are just the principal "phases" of the operation lifecycle, e.g. resolving endpoint, serializing. There's no real hard list of this anywhere, the closest thing we have to that might be the lifecycle breakdown in the (unpublished) client reference architecture.

The more niche ones were giving Initialize a span, and the outer BuildRequest (basically everything from serialize to build), I wanted to generally contain those since

1. customizations go there
2. I wanted the top level of root spans to roughly add up to the overall duration. Without the BuildRequest one, you'd basically have OperationSerializer in an oasis of un-spanned (well root spanned but yes) work.