Adopt distributed tracing

[ptoffy]

This adopts tracing on DatabaseQuery, only using async/await interfaces.
This relies on #647

[slashmo]

@ptoffy How do you expect this to look like once database drivers like postgres-nio gain tracing support? I'd assume they'd create child spans of the fluent spans? In that case I'm not sure we should follow the OTel semantic conventions for the Fluent spans at all. I looked at gorm's tracing support and they e.g. add gorm-specific spans rather than the underlying DB spans: https://github.com/go-gorm/opentelemetry

[ptoffy]

@slashmo Yes my idea is to create child spans in the underlying drivers but that might still be a while off since I'm pretty sure those are all event loop based (see https://github.com/vapor/fluent-postgres-driver). Maybe @gwynne has some insight into this.
Is there a reason you want to follow gorm instead of the OTel convention? I'd be more inclined to follow the spec since there is one

[slashmo]

Is there a reason you want to follow gorm instead of the OTel convention? I'd be more inclined to follow the spec since there is one

I'm all for following the spec. However, there isn't one for ORMs, only for db drivers. So if we'd follow the DB driver conventions here we'd have duplicate spans between Fluent and the drivers. Gorm is just one example ORM where I found built-in tracing support, and they don't follow the DB driver conventions.

[ptoffy]

@slashmo what do you think about emitting driver-agnostic traces (like the ones that are in the PR now) in fluent-kit and leaving db-specific traces up to the drivers to implement? The drivers rely on fluent-kit anyway so you'll always have both. The only pain about this approach I can think of is keeping track of which ones are where, but we can just decide it upfront

[slashmo]

Depending on how strict observability backends are about the semantic conventions I could see this being a problem. For example, if they look for certain required attributes that we don't supply here I could imagine it breaking their visualization of database spans. I think I'd slightly be in favor of using non-spec operation name and attributes for FluentKit spans for that reason. I also think it shouldn't be up to the Vapor DB drivers to add spans but the underlying database libraries agnostic from Vapor, like postgres-nio. This way we'd also benefit from these spans in apps not using Vapor.