This was inspired from commit b63335b
(see rpc.rs therein).

Just examine the hash map, do not allocate any copies.

Co-authored-by: Mikhail Zabaluev <mikhail@informal.systems>

Add tracking_id method to use in tracing instead.

Also, use less cryptic span names in send_messages_*.

Make the tracking ID construction parameter generic to accept any
Into<String> parameter.

Identify TrackedMsgs batches for creating channels and connections
with the specific message that is used.

Add OperationalInfo that can hold the displayable data on the batch,
either borrowed or owned with transforming from first to the other.
Implement Display on the OperationalInfo instead of OperationalData
for clarity.

Use the `odata` key in tracing.

The operation name is usually enough.

The task lifetime is better tracked with a tracing span,
which also reduces code repetition in tracking macros by putting in
the task name once.

spawn_background_task receives a Span constructed by the caller.
This allows embedding contextual information for the task, which is
used to reduce repetition in logging macros for the workers.

With spans injecting all of the information that was formatted
using the RelayPath Display impl, this is redundant.

For the batch worker tasks, we should have a span with the task name
and other details, so the top-level span is not needed.
For other supervisor tasks, the span name is shortened.

We have the span now, these are redundant and bad style.