Investigate missing coverage of inferred spans in observability challenge

[JonasKunz]

@AlexanderWert tried out the Observability Challenge with EDOT java and the inferred spans feature.
Apparently the application has a built-in bottleneck of a too small pool (maybe thread) which is used within transactions: This causes the transactions on load to take several seconds in response time, but those gaps are not covered by inferred spans. We should investigate why these are not uncovered and see if we can find a fix.

[jackshirazi]

If a span is started, then the thread it's on just sits there blocked on a jvm lock or queue or thread pool because it's waiting for a resource, I think there would be nothing the profiler would see because the Java core methods are ignored by the profiler. You'd have to explicitly include these with OTEL_INFERRED_SPANS_EXCLUDED_CLASSES/OTEL_INFERRED_SPANS_INCLUDED_CLASSES

[JonasKunz]

Those methods are ignored yes, but the caller waiting on the thread pool to be available (=application code) should be covered by an inferred span I think.