Instrument Tokio Resources

[seanmonstar]

Part of #39

Each "resource" in Tokio should be instrumented with a tracing span that is created when the resource is constructed. The span should be entered on the relevant poll_* methods of that resource (perhaps with an inner span identifying that specific method/action). The resources would probably have spans with different metadata, so the optimization used in the subscriber to store the metadata pointer may not work. The span name should be unique enough, but probably also the same among all the resources, with the specific kind being a structured field, so that adding new resource types doesn't require modifying the Subscriber to support them. It also allows other runtimes or engines to define their own resource types unknown to us.

Once those details are proposed, we could start with a simpler one, like timers, to prove it out (and easily view them with the example app in this repo, which is based around timers).

[zaharidichev]

@seanmonstar, how about this to begin with:

main resource span

• name - "resource"
• kind - a general resource name such as timer, chan, file, etc
• type - the exact rust type of the resource that owns the span (Sleep, File, RwLock)
• additional fields - should be specific to the resource in question. For example, for Sleep or timers in general we might want to have start(construction) and end times, while for
• File there should be a path.

operation specific spans:

• these are just child spans for each poll_* ops of resources. There can be a field identifying the method name.

If that sounds well, I can start with timers and wire them to the console?

[seanmonstar]

That sounds good to me! I'd say let's just pick good initial choices and get going. When we figure out #41, it's easy to change a few names.