Add a targetSearchConcurrency parameter to LogMergePolicy.

[jpountz]

This adds the same targetSearchConcurrency parameter to LogMergePolicy that #13430 is adding to TieredMergePolicy. The implementation is simpler here since LogMergePolicy is constrained to only merging adjacent segments.

From simulating merging on an index that gets appended 555 equal-size segments (like nightly benchmarks) and a targetSearchConcurrency of 8, I get the following results:

• 19.1 segments in the index on average, vs. 11.1 with a targetSearchConcurrency of 1.
• Maximum number of segments in the index of 28, vs. 22 with a targetSearchConcurrency of 1.
• Write amplification through merging of 3.6 instead of 2.9. For comparison, 3.6 is about the write amplification that you get with a merge factor of 7 otherwise.
• The resulting index has 24 segments, including 11 segments on the highest tier, vs. 15 segments and 5 segments on the highest tier with a targetSearchConcurrency of 1.

[github-actions]

This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the dev@lucene.apache.org list. Thank you for your contribution!

[stefanvodita]

Looks good! Thank you for following up on #13430. Do you want to add a CHANGES entry?

[jpountz]

Thanks for looking @stefanvodita! I added a CHANGES entry and improved the logic to not apply a threshold on the doc count for merges below the min merge size. I will merge soon.

[jpountz]

improved the logic to not apply a threshold on the doc count for merges below the min merge size

Woops I need to revert this for now. This made sense for TieredMergePolicy but this causes some test failures with LogMergePolicy in the corner case when minMergeSize maps to a bigger merge than maxMergeDocs.