Muzzle checks transitive dependencies which causes confusing errors

[anuraaga]

For example, jetty-8.0 depends on servlet-3.0. If there is a problem in the muzzle configuration of servlet-3.0, it is the jetty-8.0 muzzle task that complains which is deceptive

> Task :instrumentation:jetty-8.0:muzzle-AssertPass-org.eclipse.jetty-jetty-server-9.4.11.v20180605 FAILED
FAILED MUZZLE VALIDATION: io.opentelemetry.auto.instrumentation.servlet.v3_0.Servlet3Instrumentation mismatches:
-- io.opentelemetry.auto.instrumentation.servlet.v3_0.CountingHttpServletRequest:34 Missing class io.opentelemetry.auto.instrumentation.servlet.v3_0.CountingHttpServletRequest

Neet to be very careful in looking at the class name Servlet3Instrumentation in that log, but it would be nicer if transitive was just not checked since it'll be checked by other muzzle tasks anyways.

[trask]

@anuraaga can we close this now that the helper class list is auto-generated?

[anuraaga]

It's much harder to fail muzzle indeed. I think if it's possible it would be nice if muzzle didn't have confusing output for transitive but maybe it's not really feasible.

[mateuszrzeszutek]

Another case of this happened in #4627

When I included netty-4.1 instrumentation in reactor-netty-1.0 as implementation dependency the muzzle check started failing - that happened because the netty instrumentation module always matched, even if the checked reactor-netty version was supposed to fail.

[trask]

I ran into this again also, added a new option excludeInstrumentationModule to the muzzle directive to suppress the InstrumentationModule that is brought in via transitive dependency

[mateuszrzeszutek]

I think we can consider this issue closed by #6044