[exporterhelper] Introduce batching functionality

[dmitryax]

This change introduces new experimental batching functionality to the exporter helper. The batch sender is fully concurrent and synchronous. It's set after the queue sender, which, if enabled, introduces the asynchronous behavior and ensures no data loss with the permanent queue.

Follow-up TODO list:

• Add pre-built merge funcs for pdata
• Handle partial errors
• A missing part compared to the batch processor is the ability to shard the batches by context value.

Updates #8122

[codecov]

Codecov Report

Attention: Patch coverage is 93.18182% with 12 lines in your changes are missing coverage. Please review.

Project coverage is 90.95%. Comparing base (2fe7ed8) to head (8c83fd7).

Files	Patch %	Lines
exporter/exporterhelper/batch_sender.go	95.16%	4 Missing and 2 partials ⚠️
exporter/exporterhelper/common.go	79.31%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8685      +/-   ##
==========================================
+ Coverage   90.92%   90.95%   +0.02%     
==========================================
  Files         348      350       +2     
  Lines       18401    18576     +175     
==========================================
+ Hits        16732    16895     +163     
- Misses       1346     1354       +8     
- Partials      323      327       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[michalpristas]

trying to understand a behavior of this all a bit.
i wonder if it would be valuable to merge req1 and req2 Contexts into a single context. here, behavior may not be deterministic when considering cancelable contexts or contexts with Deadlines.

it would be worth to think about how batch should behave in case one of the contexts expires
also what in case of different spans related to these contexts

queue sender creates a noCancellationContext maybe this could do the same just in case queue is not used after batch

[dmitryax]

@michalpristas, this is a good question. In the current implementation (which is similar to the current batch processor), we should pass only one context from the request that is currently being added to the batch and is blocking the current Consume call. We can ignore the context associated with the existing batch because all the other requests are already accumulated in the batch and are not active anymore.

But if the queue is not enabled, we probably want to block all the incoming requests until a batch is ready, as discussed in #8762. In that case, we probably need some kind of context merging. That option is not implemented yet.

[dmitryax]

The blocking behavior is implemented now.

I looked into merging contexts of requests that create a batch.

There was a proposal to implement this capability natively in go golang/go#36503, but it was declined.

We could manually merge the contexts, but it would require spawning another goroutine specifically to handle the context cancellations. I think this is an overkill for this task. I think it's ok just to take the context from the first request, assuming that it has the shortest timeout. I updated the code accordingly. Let me know WDYT.

[mx-psi]

This looks good for a first version, specially considering we are marking it as experimental. I think we need to see it used in components and see how it fares in real life so I am approving