experiment: prototype measurement processor

[martintmk]

In this PR I am trying to experiment with dynamic metric enrichment. This API tries to do the enrichment in a naive way and should not affect he performance if this feature is not used.

I have experimented with using Cow<'a, [KeyValue]> as an argument to the processor. The processor might decide to not modify the attributes and, in that case, the original slice is returned without any additional allocations.

When measurement processors are not used, I have not detected any changes in throughput.

Fixes # Design discussion issue (if applicable) #

Changes

Please provide a brief description of the changes here.

Merge requirement checklist

• [ ] CONTRIBUTING guidelines followed
• [ ] Unit tests added/updated (if applicable)
• [ ] Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• [ ] Changes in public API reviewed (if applicable)

[Blinkuu]

Hey @martintmk, I love this experiment!

We have a formal proposal for the MeasurementProcessor concept, which you can find here: https://github.com/open-telemetry/opentelemetry-specification/pull/4318

It would be wonderful if you could slightly refactor this PoC to follow the proposal. This would help with getting the proposal merged.

From a functional standpoint, it would require redefining the MeasurementProcessor trait from:

pub trait MeasurementProcessor: Send + Sync + 'static {
    fn process<'a>(&self, attributes: &[KeyValue]) -> Option<Vec<KeyValue>>;
}

to something like:

pub trait MeasurementProcessor: Send + Sync + 'static {
    fn process<F>(&self, measurement: Measurement, next_processor: F)
    where
        F: FnOnce(Measurement);
}

Note: Please forgive me if the above doesn't make sense - I don't write Rust :D