chore: Use span fields as metrics labels

[MOZGIII]

Closes #2660

Commits are semantic, should be easy to follow along through history.

[Hoverbear]

This overall looks good!

[MOZGIII]

metrics-rs/metrics#87 has been merged, will switch the crate at Cargo.toml after new 0.13-alphas ship!

[MOZGIII]

I found out that the notation we're using at topology at spawn_sink, spawn_transform and spawn_source injects the name and type as span data. I presume this is what we want to capture. One downside there is that names are a bit too generic, and can be easily overwritten in inner spans or logging calls.
I suppose this on it's own is not a good idea, and we should probably name them a bit more distinctively.

Also, the code I have filters by component_name annotation, but we can easily add more fields. We can't check the span name currently (i.e. to only grab the data from the sink/transform/source) - it's doable, but it doesn't seem like a good approach in the first place because it doesn't help with potential overrides at logging calls caused by inner spans or literal arguments at callsite. We probably want to just solve all those at once via specifying different span field names.

CC @lukesteensen

[binarylogic]

I don't mind either way, but I would choose component_id and component_type for the context names.

[bruceg]

Looks okay, though the title really underplays what is going on here as it looks like a significant rework of our internal metrics underlay.

[MOZGIII]

I don't mind either way, but I would choose component_id and component_type for the context names.

Ended up using topology_component_name and topology_component_type, because the component_type is already used as a literal value at the the emit!s.

Did a test run - it works great in practice. I suggest interested parties take the final look. I'll probably merge this on Monday.

[binarylogic]

Yeah, I'd prefer that we use component_name and component_type if possible. Can we not fix that? Not a huge deal if not.

[MOZGIII]

@binarylogic I’d prefer that we don’t define the same field in two locations to eliminate the confusion with where they come from. So, I suggest removing the literals component_type from the emit! invocations from each of the components.
Alternatively, we can remove the component_type from the toolpology.

Not removing any would lead to metrics having two component_type labels with potentially different values (in the case where source is composed using other source/transform for instance).

@lukesteensen what do you think?

[binarylogic]

It's fine. You've got 2 approvals, let's merge.

[lukesteensen]

I suggest removing the literals component_type from the emit! invocations from each of the components.

Yes, my assumption was that we'd remove the manual tags from the event definitions once we're able to derive them from the span data. This is especially important for events that are emitted from shared components, where we previously couldn't know the exact type statically.

[MOZGIII]

I'll create a follow-up PR to put this in order.