supress zipkin exporters instrumentations

[chungngoops]

draft PR for #5967

[SylvainJuge]

Suggested change

	import io.opentelemetry.exporter.internal.InstrumentationUtil;
	import io.opentelemetry.api.internal.InstrumentationUtil;

Should be updated to use the new API introduced in #6546

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.06%. Comparing base (ad120a5) to head (46e05d6).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #6552   +/-   ##
=========================================
  Coverage     90.05%   90.06%           
- Complexity     6275     6276    +1     
=========================================
  Files           697      697           
  Lines         18944    18949    +5     
  Branches       1858     1858           
=========================================
+ Hits          17060    17066    +6     
  Misses         1307     1307           
+ Partials        577      576    -1     

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

[codefromthecrypt]

for test what i would expect to see is a new test in ZipkinSpanExporterTest which weaves in the same code (maybe via copy paste) as tests done here

opentelemetry-java/exporters/sender/okhttp/src/test/java/io/opentelemetry/exporter/sender/okhttp/internal/AbstractOkHttpSuppressionTest.java

Line 19 in 6fc1d21

abstract class AbstractOkHttpSuppressionTest<T> {

let me know if other hints would help

[codefromthecrypt]

another hint is remember BytesMessageSender is a type you can wrap. so you can catch the suppression by customizing this in your test. ThIs would result in the same confidence as the existing okhttp test I mention, basically if you can read the suppression intent is done, the test is good. this is different than an end to end test but may be enough to close this out.

[jack-berg]

I don't understand how this test is exercising the code added in this PR.

[chungngoops]

I updated the test.

[codefromthecrypt]

Maybe think of it a different way, make a fake sender, not a real one.

Then pass that to ZipkinSpanExporter ctor.

Then in a suppression closure, do the actual export

After the closure, you can verify sent() and suppressed()

make sense?

class SuppressCatchingSender extends BytesMessageSender.Base {
  AtomicBoolean sent = new AtomicBoolean();
  AtomicBoolean suppressed = new AtomicBoolean();

  SuppressCatchingSender() {
    super(Encoding.JSON);
  }

  @Override public int messageMaxBytes() {
    return 1024;
  }

  @Override public void send(List<byte[]> encodedSpans) {
     sent.set(true);
     suppressed.set(InstrumentationUtil.shouldSuppressInstrumentation(Context.current()));
  }

  @Override public void close() throws IOException {
  }
}

[chungngoops]

Thank you very much for your help.

[codefromthecrypt]

LGTM (non-binding approve)