If spans are started or removed by two threads at the same time, or one tries to write the context to bson while another thread is changing a span, a data race occurs.

The mutex around the OtelContext should be fine, as not many threads will attempt to read this at once, and it's only hit in cases where we have an ongoing trace, so rare. We will do performance testing in the future with tracing on, and if this is problematic we can look to optimize then.

Moving the sampling roll to the constructor simplifies making the class thread-safe. While it is possible to make it lazy, thread safe, and fast, it's just more complicated, especially considering how clone will have to do something special to handle it.