Tracing improvments

[PetrichorIT]

Some improvements to tracing with turmoil:

• All nodes now have a node-span, to add information about the currently active node to all tracing events
• These spans are stored in Rt and Host to cover all codepaths that may emit events
• All internal tracing events now share a common structure (src,dst, ..., msg)
• src now always represents the source of the packet, the tracing record was about (src of SYN is client, src of SYN-ACK is server)

[davidbarsky]

Generally speaking, you shouldn't need to pass a tracing::Span to usage sites: you can create a new one at the usage site and tracing will figure out the appropriate parentage/hierarchy automatically.

[mcches]

Tagging #49.

[PetrichorIT]

@davidbarsky since spans are entered 3 times pre tick, it seems wasteful to me to create the span inline,
since they require custom fields generated from a reverse dns request each time. The core idea behind passing
the span to the appropriate usage site is to minimize dns queries and string allocation. Would you consider the performance impact of span creation significant enough to warrant this unusual structure or should we just switch to inline-creation of spans, say with a shared Arc<String> to minimize reverse dns queries?

[davidbarsky]

Would you consider the performance impact of span creation significant enough to warrant this unusual structure or should we just switch to inline-creation of spans, say with a shared Arc<String> to minimize reverse dns queries?

Creating spans and events is generally pretty cheap, especially if they are disabled and filtered out. I think keeping an Arc<str> around, especially if it's expensive to fetch, is perfectly reasonable.

[mcches]

A couple minor comments. This will be really nice for debugging.