Add support for event driven framework

[lalitb]

This would be eventually required for

• To support async interface between span/log processor and exporters.
• Async IO while exporting the spans.
• Timers to poll for Spans in BatchSpanProcessor, and metrics in PeriodicMetricReader.
• Asynchronously collect metrics for all the instruments across all the meters ( this would be a costly operation sequentially or even using threads).

References:

• 63 - Initial work has been done in this PR.

• hiredis: event adaptor used by Redis database as suggested by @owent
• libwebsockets - Suggested by @owent

[github-actions[bot]]

This issue was marked as stale due to lack of activity. It will be closed in 7 days if no furthur activity occurs.

[github-actions[bot]]

Closed as inactive. Feel free to reopen if this is still an issue.

[owent]

Note: This issue is simular to https://github.com/grpc/grpc/issues/20194 of grpc

We should also support to share our event loop with grpc's in the future.

[amirouche]

Quoting https://github.com/grpc/grpc/issues/20194#issue-490393542:

In order for an API to integrate into a foreign event loop, it needs to provide a polling interface as well as a callback function which can be used to signal a mutex condition to wake up, or activate an eventfd, or put an item on a kqueue, etc.

To develop on Zig's Andrew comment, nested quote above:

Say opentelemetry-cpp client (OTC) has its own whatnot event-loop, then to integrate that event-loop to a hosting application (APP) that has also an event-loop; OTC need to provide:

1. a way to notify APP that OTC has io work to do [^1]
2. a way to wake up OTC's event-loop for one iteration [^2]

[^1]: it may be polling as an OTC function that is regularly called by APP; or nest epoll_create1 fd, or io_uring_setup fd; [^2]: see libuv's UV_RUN_ONCE to actually do the io work;

That should work when there is a dedicated POSIX thread for OTC's whatnot event-loop running the exporter. It is also the best time-to-market way to make OTC work better with async apps.

There is more work if OTC's event-loop need to run in the same POSIX thread as APP's event-loop; and there is even more work if OTC need to re-use APP's event-loop. In the latter case, OTC requires something like an n+1 eventloop library ala hiredis, and libwebsockets adapters.

Next step is too choose what "integration" opentelemetry-cpp need:

1. Dedicated POSIX thread => Choose an eventloop library;
2. APP, and OTC have different eventloops in one POSIX thread => Choose an eventloop;
3. APP, and OTC share the same eventloop;

At some point to achieve the "async dream" exporters will also need to be aware of OTC's event-loop; in the meantime, we call Exporter::ExportResult, and Exporter::ForceFlush in one-shot POSIX threads;