Description
I'm concerned that the TaskMonitor creates a bit of an anti-pattern for instrument task metrics in certain cases. It is leading the user to aggregate across tasks. That makes sense for background tasks or other tasks that don't have a useful 1:1 mapping with some sort of foreground context.
However, things like a task for a request handler or some other foreground operation, are useful to have individual data points for. Since, then you can map a tasks's tokio metrics directly against errors, timeouts, log lines, traces, etc.
It seems like this library would be a sensible place to have some machinery for also conveying similar metrics, but not aggregated.
Maybe some sort of wrapper future that returns both the inner future's result, along with the final TaskMetrics state? Along the lines of future-timings, but also with task-related handling? It could probably mostly use the same TaskMonitor...
And then, if we have that, we should offer clear guidance around when it generally makes sense to use individual vs aggregated metrics. IE, add some language in the README + crate docs, presumably.