Align merging defaults with Lucene's new defaults.

[jpountz]

Lucene recently updated its merging defaults to bias a bit less towards indexing performance and a bit more towards search performance by:

• Increasing the floor segment size from 2MB to 16MB. Segments between 2MB and 16MB will now be merged more aggressively. This is expected to result in ~10 fewer segments per shard.
• Decreasing the number of segments per tier from 10 to 8. This is expected to result in 20% fewer segments between 16MB and 5GB (the min and max merged segment sizes).

This PR aligns Elasticsearch's defaults with these new Lucene defaults. This should especially help queries that have a high per-segment overhead, such as multi-term queries (e.g. fuzzy queries) and vector search. On the other hand, indexing performance may decrease a bit due to more merging.

Note that time-based data (indexes that have a @timestamp field) have their own merge factor of 32, so they only get the bump of the floor segment size to 16MB, not the decrease of the number of segments per tier.

Furthermore, Lucene now allows merging up to maxMergeAtOnce segments if the merged segment size is below the floor segment size (16MB by default). When maxMergeAtOnce is greater than segmentsPerTier, this helps tiny segments grow more quickly with less write amplification. So to take advantage of it, I bumped maxMergeAtOnce from 10 to 16. This anticipates upcoming behavior in Lucene 11 where maxMergeAtOnce gets removed and Lucene will happily merge lots of segments together in a single merge as long as the merged segment size is below the floor segment size.

Closes #120624
Closes #129764
Closes #130328

[elasticsearchmachine]

Pinging @elastic/es-distributed-indexing (Team:Distributed Indexing)

[elasticsearchmachine]

Hi @jpountz, I've created a changelog YAML for you.

[henningandersen]

LGTM.

[henningandersen]

This can potentially cause serverless tests to fail though I'd expect the PR build to catch that (looks like it successfully ran serverless tests). We saw that when the lucene default changed. Perhaps we can run one more CI run (to get another randomized sample)?

[jpountz]

Thanks @henningandersen. I'm running CI tests once again.

[jpountz]

I cannot see the connection between the elasticsearch-ci/bwc-snapshots-part2 failure and this PR.

Regarding the Serverless test failure (SearchCommitPrefetcherIT), I wonder if the failure happens due to the number of commits being greater than 8, which triggers a background merge. If this is the case, changing the number of commits from randomIntBetween(5, 8) instead of randomIntBetween(5, 10) should fix the issue.

[brianseeders]

buildkite test this

[henningandersen]

buildkite test this