[exporter][batcher] Multi-batch support - Version 2

[sfc-gh-sili]

Description

This PR introduces two new components

• Partitioner - an interface for fetching batch key. A partitioner type should implement the function GetKey() which returns the batching key. Partitioner should be provided to the queue_bacher along with sizer in queue_batch::Settings.
• multi_batcher. It supports key-based batching by routing the requests to a corresponding default_batcher. Each default_batcher corresponds to a shard described in Exporter batcher dynamic sharding of the partitions #12473.

Link to tracking issue

#12795

Testing

Documentation

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.57%. Comparing base (8a190ed) to head (57c510d).

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12760      +/-   ##
==========================================
+ Coverage   91.55%   91.57%   +0.02%     
==========================================
  Files         499      500       +1     
  Lines       27102    27169      +67     
==========================================
+ Hits        24814    24881      +67     
  Misses       1809     1809              
  Partials      479      479              

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jmacd]

What question(s) are there? I'm not sure I'm following.

[sfc-gh-sili]

This comment is duplicated from newDefaultBatcher(). IIUC, this is related to how goroutines are allocated when async queue and the batcher are used together. Right now:

• AsyncQueue owns a goroutine pool of size n that is in charge of reading from the queue and calling Batcher::consume().
• Batcher::consume() is in charge of appending the new item to the batch and invoking the flushing goroutine if needed
• Batcher can allocate up to m goroutines for dispatching the active batch.

Both n and m come from the same config field sending_queue::num_consumers, but it does not necessarily make sense use the same number of goroutines for "reading from queue" and "dispatching the request'

[dmitryax]

Do we need to have another batcher at all (multiBatcher)? I see significant amount code duplication. Maybe we just update defaultBacher instead where the getShard just returns a singleton if partitioner == nil?