Add a KeyName argument to LabelFilter::should_include_label

[zohnannor]

On the project I'm working on, we have to filter excessive metric labels added by TracingContext after the fact, but it could be better if we could see metrics' names in the process of TracingContext::enhance_key. And the inner workings of MetricsLayer doesn't allow us to create custom Layer+Recorder to efficiently add only required metric labels.

This PR adds name: KeyName argument to LabelFilter::should_include_label method to pass from TracingContext::enhance_key, that way custom LabelFilter, that can filter labels by the name of the metric and label key/value, is an option. Bumped metrics-tracing-context version to 0.13 because it's a breaking change.

[ilslv]

In case this is a concern, we can avoid breaking changes by adding a method with a default impl to LabelFilter trait.

pub trait LabelFilter {
    fn should_include_label(&self, name: &KeyName, label: &Label) -> bool;
    fn should_include_label_by_name(&self, name: &KeyName, label: &Label) -> bool {
        self.should_include_label(label)
    }
 }

[tyranron]

@zohnannor

I also replaced Vec<Label> with SmallVec<[Label; 5]> in the Labels to improve performance (ran the benchmarks a couple of times, but buffer of 5 elements is not tested to be the best option).

I'd say these changes better go as a separate PR. Also, it seems that [Label; 3] is more meaningful and much more common use-case.

[zohnannor]

@ilsiv Totally! I was thinking of writing it like that...

@tyranron Yes, it is unrelated, removed that from this PR.

Changed PR name & description to reflect new changes.

[tobz]

Exciting to see so much activity in a PR before I even open it. 😍

I'll try and take a look at this today.

[tobz]

Looks good to me!

I'll sort out the CI stuff separately after merging.

[tobz]

Released as metrics-tracing-context@0.13.0.

Thanks again for your contribution!