Allow building ServerMiddleware without a TracerProvider

[arturaz]

You don't always want to use a TraceProvider, sometimes you just want to extend another trace.

For example, I start my trace a bit earlier, to capture client span, and therefore, I use my own TraceProvider.

This breaks binary compatibility, but I figured that is OK, given that 0.11 changed the API anyway.

My usecase for the curious:

• https://github.com/arturaz/scala-web-framework/blob/main/server/src/framework/http/middleware/ClientRequestTracingMiddleware.scala
• https://github.com/arturaz/scala-web-framework/blob/43e4b6795de09c034f0a218017ee038d1f8d01e3/server/src/framework/utils/FrameworkHttpServer.scala#L75-L82

[NthPortal]

@arturaz you can use separate Tracers within a single trace as long as they both came from the same Otel4s instance^†. if you want to create a new span within a span created by a different Tracer from the same Otel4s, it will Just Work™. additionally, if you want to modify a span created by a different Tracer from the same Otel4s, the Tracer#currentSpan{Context,OrNoop,OrThrow} family of methods will all access the current span exactly as desired.

you don't actually even need to use the same Otel4s^‡ as long as you propagate the trace and span information, as is done over requests between different services.^⸸

This breaks binary compatibility, but I figured that is OK, given that 0.11 changed the API anyway.

0.11 isn't even out yet; if I'm convinced this is a good idea, RC 1 will just not be binary compatible with the release. I think my comment addresses your concerns, but please let me know if I'm wrong

---

^† what's important is actually just that they use the same LocalContext, which coming from the same Otel4s guarantees
^‡ or LocalContext
^⸸ "did you really need footnotes?" not really, i just think daggers are fun