api: support Formatter trace tag

[zirain]

xref: envoyproxy/envoy#41697

this's useful when users want to add value REQUESTED_SERVER_NAME to tag.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.33%. Comparing base (fb389ff) to head (09213f2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7485      +/-   ##
==========================================
- Coverage   72.37%   72.33%   -0.04%     
==========================================
  Files         232      232              
  Lines       34143    34143              
==========================================
- Hits        24711    24698      -13     
- Misses       7659     7670      +11     
- Partials     1773     1775       +2     

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[arkodg]

any reason we have 2 level here ?
does the similar field for access log use the same field name of formatter ?

[zirain]

there're two reasons why I used FormatterCustomTag here:

1. keep same pattern with others type.
2. in case there's more options in the future.

[jukie]

Name does align with the changes from envoyproxy/envoy#41697

[arkodg]

rethinking this one, do we need an explicit API field for now, in header.value case, we reuse the same field for literal and formatter string, can we do the same here ?

[zirain]

rethinking this one, do we need an explicit API field for now, in header.value case, we reuse the same field for literal and formatter string, can we do the same here ?

if there's no type, it's fine.

rethinking this one, do we need an explicit API field for now, in header.value case, we reuse the same field for literal and formatter string, can we do the same here ?

We can change the underlying layer of literal to this new formatter type, which is supported.

[arkodg]

rethinking this one, do we need an explicit API field for now, in header.value case, we reuse the same field for literal and formatter string, can we do the same here ?

if there's no type, it's fine.

rethinking this one, do we need an explicit API field for now, in header.value case, we reuse the same field for literal and formatter string, can we do the same here ?

We can change the underlying layer of literal to this new formatter type, which is supported.

sure sgtm