Save memory when string terms are not on top

[nik9000]

This reworks string flavored implementations of the terms aggregation
to save memory when it is under another bucket by dropping the usage of
asMultiBucketAggregator.

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

[nik9000]

In my tests this makes the map execution mode slightly faster when the terms agg is collected from many buckets but doesn't really do anything to the global_ordinals case. But I think my test case is super high cardinality so the performance of adding buckets is dominating the run time. It should indeed save memory. Especially on highly nested aggregations.

[nik9000]

I'm putting together a lower cardinality test case to see what that does.

[nik9000]

When the terms aggregation is inside another aggregation and cardinality is high (~5 million buckets collected), this is flat for performance for global ords and marginally better for the "map" strategy (before after). When the cardinality is lower (~30 thousand buckets collected) this is about 15% faster for global ords (before after).

I expect this is because LongKeyedBucketOrds isn't really optimized at all. We could and should do better here. But that is a thing for another PR.

It uses much less memory for the "map" strategy when the terms agg is a child of a high cardinality agg because the bucket collection strategy can share the map of terms.

@polyfractal had asked me about the performance difference for map vs global_ordinals. In this particular test global_ordinals is about 65% faster for the 30k bucket case and about 40% faster for the 5m bucket case. But this does a disservice to global_ordinals because non of the "interesting" optimization kick in here because the terms is a sub-agg. If terms is on top we can use the sparse strategy or the low cardinality strategy, both of which claim to be faster.

At some point we could indeed investigate using those strategies with the terms is a sub-agg. In particular, I'd be interested in cases when there isn't any correlation between the value of the parent agg and the terms agg. In that case we could benefit from the "dense" strategy even when we are a sub bucket. We'd end up spending 8 bytes per bucket rather than 24 which is lovely. And there'd be no hashing whatsoever to get the bucket which'd make the lookups faster.

[not-napoleon]

LGTM

[not-napoleon]

Oh, that reminds me, I should put a private default constructor on ValuesSourceConfig, thanks.

[not-napoleon]

How confidant are we that this assert will never trip? I'm wondering if it makes sense to change the condition to read if (remapGlobalOrds || collectFromSingleBucket==false)

[nik9000]

I'm pretty confident. But I'll switch it to a hard check just for extra assurance.

[nik9000]

run elasticsearch-ci/default-distro