Prepare foundations for multi-consumer tracing output

[TheJokr]

• Introduce optional limit for span queue size.
• Add metrics for total spans, dropped spans, current span queue size, and maximum configured span queue size.
• Add tokio::sync::mpsc receiver wrapper to allow multi-consumer semantics. The next PR will introduce the option to start multiple consumer tasks.
• Use batching recv_many calls in Jaeger UDP tracing output.

I reviewed all the well-known async MPMC queue implementations prior to landing on the async mutex wrapper for tokio's own channels. The common problem shared by almost all MPMC implementations is that they do not support batch receive operations (i.e., recv_many). This, combined with the bad locality of single-queue MPMC channels, makes me believe a Mutex-wrapped MPSC channel with batch receives will perform better for the tracing use case.

There are 2 MPMC implementations that do offer batching (batch-channel and burstq). These don't work for our use case either:

• burstq pre-allocates the entire channel size, which is prohibitive since we expect to only use a fraction of it >99% of the time.
• batch-channel does batching inside the sender. This means sending requires exclusive ownership over the sender, so we would have to put it inside a Mutex to share it between spans. This moves the locking from the (few) consumer tasks to the many, many spans that may be generated.

In contrast, the Mutex-wrapped MPSC receiver will have 1 active receiving task at any time and a FIFO queue of other tasks waiting to become the active receiver next. The active receiver gets a batch of spans, and while the Mutex is passed on to the next task a new batch accumulates in the channel.

We can revisit this decision with production metrics later on if needed.