refactor: make baggage::KeyValueMetadata private

[gruebel]

Relates to #2748 (comment)

Changes

@cijothomas let me know, if you had this in mind. if it is too inconvenient to use 2/3 value tuples, then we can also keep the current implementation

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)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.7%. Comparing base (9d3a507) to head (ec463d2).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2763   +/-   ##
=====================================
  Coverage   79.7%   79.7%           
=====================================
  Files        123     123           
  Lines      23107   23109    +2     
=====================================
+ Hits       18426   18428    +2     
  Misses      4681    4681           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cijothomas]

Can you share a code snippet of before/after that users have to do due to this change? That'll make it easy for us to make a decision. (Also, after looking at KeyValueMetadata struct, it not a concern to keep it public either.)

[gruebel]

Instead of creating it directly, like

KeyValueMetadata::new("key1", "val1", "prop1")

you have to pass it as a tuple

(KeyValue::new("key1", "val1"), BaggageMetadata::from("prop1"))
// or
(Key::from("key1"), StringValue::from("val1"), BaggageMetadata::from("prop1"))

as said, if keeping KeyValueMetadata public is ok, then there is no real benefit to go with this approach

[cijothomas]

Instead of creating it directly, like

KeyValueMetadata::new("key1", "val1", "prop1")

you have to pass it as a tuple

(KeyValue::new("key1", "val1"), BaggageMetadata::from("prop1"))
// or
(Key::from("key1"), StringValue::from("val1"), BaggageMetadata::from("prop1"))

as said, if keeping KeyValueMetadata public is ok, then there is no real benefit to go with this approach

Agree to keep the existing and keep KeyValueMetadata public. Let us close this PR.
(Thanks for exploring and writing up this!)