follow more closely the official OTEL recommendations, and also try
to reduce global state.
- use a class type for `Exporter.t` (instead of 1st class module `backend`)
- have tracer, logger, metrics_emitter as explicit objects
- keep a `Main_exporter` to make migration easier, but discouraged
- add stdout_exporter and debug_exporter to opentelemetry.client
The use of a non-threadsafe mutable reference for the metrics callbacks
was resulting in a race condition that would sometimes produce
non-deterministic results in the integration tests.
This has not affected the lwt-based collector, because of the single
threaded concurrency Lwt enforces, but it began to show up in the WIP
Eio rewrite, for which I am testing on cross-domain programs.
I suspect this may have also bee affecting the ocurl collector, but we
don't have integration test running on that yet.
As discussed in https://github.com/ocaml/ocaml/issues/14078,
alerts (with deprecation alerts as a special case) are not currently
supported as item-attributes on let-bindings. This usage produces
`misplaced-attribute` warnings, such as
```
Warning 53 [misplaced-attribute]: the "deprecated" attribute cannot appear in this context
File "src/core/opentelemetry.ml", line 1229, characters 37-47:
1229 | let add_event = Scope.add_event [@@deprecated "use Scope.add_event"]
^^^^^^^^^^
Warning 53 [misplaced-attribute]: the "deprecated" attribute cannot appear in this context
File "src/core/opentelemetry.ml", line 1231, characters 37-47:
1231 | let add_attrs = Scope.add_attrs [@@deprecated "use Scope.add_attrs"]
^^^^^^^^^^
Warning 53 [misplaced-attribute]: the "deprecated" attribute cannot appear in this context
```
Fortunately, we can still add deprecation alerts to these value by
moving the alert to the pattern, as done here.
