contrib psr18 auto-instrumentation also instruments exporter

[brettmc]

Whilst doing some initial testing of the new psr-18 auto-instrumentation, with PHP 8.1 + otel dev-main, using any exporter which uses PsrTransport (everything except grpc), I noticed that it also creates spans/traces for the exporting call.

If using batch processor, that's one extra trace exported (because it happens as part of shutdown, when there is no active context).
If using simple processor, it's pathological: each span exported creates a new http request which is also exported and traced. I didn't let it continue (one trace contained 27k spans, so it would probably only stop on resource exhaustion).

First trace is with simple span exporter (request aborted after some time), second two are with batch span exporter:

Detail of simple span exporter's trace:

Proposed solution:
Create a generic way to be able to identify psr-7 requests which are exporting. My best idea so far is to add a known header such as X-Is-Otel-Exporter from PsrTransport. HTTP auto-instrumentations such as psr-18 can check for this header, and ignore it (and drop the header before it is sent), essentially a pseudo-attribute for psr-7 requests.

[pdelewski]

I don't see better solution for now. Is dropping this header necessary or it's just optimization?

[brettmc]

I don't see better solution for now. Is dropping this header necessary or it's just optimization?

It's probably not necessary to drop it, I might ask on the maintainers list whether this has come up in other SIGs. Dropping does seem unnecessary, since if there wasn't an auto-instrumentation to check/drop, it would be sent to the the collector/other endpoint.

[Nevay]

IMO we should run span processor flush and metric reader collect with the Context that was active during creation (ref).
The Globals initializer already activates noop implementations before invoking the initializers to support this / to disable auto-instrumentation of SDK requests etc. by default.