Significant terms aggregations should support breadth_first mode

[jimczi]

The significant_terms aggregation always executes in depth_first mode when sub-aggregations are provided. This mode uses a lot of memory since the sub-aggs need to be computed on all buckets. We should automatically switch to the breadth_first mode like the terms aggregation does in order to make sure that we don't use too much memory for buckets that will not survive the pruning.

[colings86]

@elastic/es-search-aggs

[jtibshirani]

From my understanding, @jimczi’s review in #29042 made two overall recommendations:

1. Unlike terms aggregations, we should always choose breadth_first because we expect the significant_terms aggregation to run on high cardinality fields.
2. Also unlike terms aggregations, the user should not be able to specify collect_mode. We can avoid exposing this 'expert' option, and just pick a sensible behavior under-the-hood.

Regarding point 1, my intuition was that we should stick with the same behavior that we do for terms aggregations. This is more flexible in that it can handle low-cardinality fields, and it didn’t look like too much overhead to maintain the extra logic. I think it also gives better predictability, because a significant_terms aggregation will have the same behavior as a terms aggregation against the same field.

For 2, I was wondering what the intuition was behind not allowing collect_mode to be specified for consistency with the terms aggregregation? Have users shot themselves in the foot with it in the past?

[polyfractal]

@elastic/es-analytics-geo

[jimczi]

We discussed this internally and @markharwood had a good point about the fact that this aggregation was not meant to be used with children aggregations. The reasoning is that it is useful to extract significant terms but the analysis on these terms should be done separately. The fact that we select a top N that can differ on each shard makes the accuracy of children aggregation worse that when using a simple terms aggregation. One thing we could do is to disallow children aggs completely but this would have an impact in terms of BWC so we agreed to handle this issue separately. Regarding the discussion points we also agreed that we don't want to add new options that would complexify this aggregation especially if we plan to remove this ability in the future. Since the pr is already quite advanced we should ensure that we always use the breadth_first mode all the time, this will prevent memory issues for users that have children aggregations seamlessly.