Reduce created segments when there is low traffic on a shard

Lucene creates 1 segment per active concurrent thread per shard. Number of active concurrent threads per shard is determined by bulk thread pool in ES, which is a worker on the queue holding sub bulk requests. Each sub-bulk request ends up being picked by a different thread, hence resulting in multiple segments during refresh, resulting in better performance during reads. When there is a low traffic on a particular shard on a node, we can potentially reduce the number of created segments by co-alescing bulk requests.

When there are lot of shards on a single node for different indices, this problem may aggravate further.

The proposal is to optimize this entire process is via the following tasks:

• Pipeline the CPU work into different tasks further (parsing, translog, lucene add) per shard
• Coalesce the lucene documents across different bulk requests by adding a separate queue for lucene adds.

The issue names no files, tests, or entry points. Start by tracing the bulk thread pool and shard indexing path to understand where parsing, translog work, and Lucene adds are scheduled. Done would require implementing and validating the proposed task pipeline and coalescing Lucene documents across bulk requests, with evidence that low-traffic shards create fewer segments.