Simplify ordering support on terms aggregations

[jpountz]

We try to be as flexible as possible when it comes to sorting terms aggregations. However, sorting by anything but by _term or descending _count makes it very hard to return the correct top buckets and counts, which is disappointing to users. Instead, I suggest that we only allow order options that result in
reasonably accurate results:

• remove the ability to sort by ascending count
• remove ordering by sub aggregations entirely, or only allow when the leaf of the path is a min or max aggregation: in that case counts will not be accurate but I believe that the top buckets will be correct.

[clintongormley]

Is this something we can possibly support with two-phase aggregations? #12316

[jpountz]

With multiple phases, we could get accurate results when sorting by min/max aggs (the first round could compute the top buckets and the second could ask all shards only for these values). This would also help refine counts when sorting by descending count since we can assume that shards have similar number of occurrences of each term. But we cannot make such assumptions for sub aggregations. For instance if you sort a terms aggregation by a sub avg aggregation, you could still get very different top terms for each shard eg. if the field that you compute the avg on has outliers.

[rashidkpc]

Please open an issue on the kibana repo if and when you start moving on this as it will be a breaking change for many of our users.

[colings86]

Discussed in FixItFriday and we agreed to split out removing the ascending count option from this issue so the conversation can be separated from removing support for sorting by sub aggregations (see #17614)