feat!: Add baggage key predicate func to baggage span processor

[MikeGoldsmith]

Which problem is this PR solving?

• Closes Baggage span processor - key predicate #956

Short description of the changes

• Add baggage key lambda as constructor parameter to baggage span processor
• Add ALLOW_ALL_BAGGAGE_KEYS lambda that allows all keys
• Add unit test to verify behaviour
• Update README with examples of setting a filter

[MikeGoldsmith]

Ping @robbkidd @arielvalentin - please could you take a look?

[robbkidd]

[MikeGoldsmith]

Thanks for the updates @robbkidd - much appreciated.

[arielvalentin]

Are there any cases where endusers may want to filter based on value as opposed to key alone?

If I were writing my own predicate I would likely want to reach for an implementation that uses Hash#slice and have an explicit key list as well as potentially scrub attributes that I may be concerned has PII in it. I wouldn't be able to do that with the current implementation.

Of course the more flexibility we provide, the more likely it will be a foot gun, so take my comments there with a grain of salt.

rant: wouldn't it be nice for the SDK to have the same attribute processors as the OTel collector

In addition to that, since this predicate does not get applied to the active span, should we communicate that somewhere in docs?

[MikeGoldsmith]

Are there any cases where endusers may want to filter based on value as opposed to key alone?

If I were writing my own predicate I would likely want to reach for an implementation that uses Hash#slice and have an explicit key list as well as potentially scrub attributes that I may be concerned has PII in it. I wouldn't be able to do that with the current implementation.

Of course the more flexibility we provide, the more likely it will be a foot gun, so take my comments there with a grain of salt.

I think if you're starting to reach for a way to scrub data, your needs are more complex than what this processor offers and you should consider creating you own. I think using the key is a nice middle ground of being aware & having some control of what's going into baggage and doing more complex / custom logic.

rant: wouldn't it be nice for the SDK to have the same attribute processors as the OTel collector

Yeah, I agree it's sometimes frustrating SDKs don't have all the same processors as the Collector. Although, then we'd need to maintain them in two places.

In addition to that, since this predicate does not get applied to the active span, should we communicate that somewhere in docs?

Sure, I can madd an extra bit to the description that newly added baggage entries are not automatically added to the active span.

[arielvalentin]

@MikeGoldsmith please update your branch, since I do not have permissions to do so and I will merge this once specs pass.

[MikeGoldsmith]

Done - thanks @arielvalentin 🎉