### Description

We have had this longstanding issue that running a top-level `filter` aggregation is often (not always, e.g. not if you need the total hit count too) a performance bug, as Elasticsearch would iterate over docs that match the `query` and would then check each of these docs against the filter of the `filter` aggregation. It's usually a better idea to put the filter directly into the query, where it can be used to drive iteration if appropriate.

We could do this automatically by implementing the `LeafCollector#competitiveIterator` API that was introduced for dynamic pruning, in order to automatically start intersecting the query with the filter of the `filter` aggregator once enough hits have been counted.
server/src/main/java/org/elasticsearch/search/aggregations/bucket/filter/FilterByFilterAggregator.java
* without sending any documents to a sub-aggregator. This yields
     * the correct response when there aren't any sub-aggregators or they
     * all opt out of needing any sort of collection.
     */
    private void collectCount(LeafReaderContext ctx, Bits live) throws IOException {
        Counter counter = new Counter(docCountProvider);
        for (int filterOrd = 0; filterOrd < filters().size(); filterOrd++) {
            incrementBucketDocCount(filterOrd, filters().get(filterOrd).count(ctx, counter, live));
        }
    }
    /**
     * Collect all documents that match all filters and send them to
     * the sub-aggregators. This method is only required when there are
     * sub-aggregators that haven't opted out of being collected.
     * <p>
     * This collects each filter one at a time, resetting the
     * sub-aggregators between each filter as though they were hitting
     * a fresh segment.
     * <p>
     * It's <strong>very</strong> tempting to try and collect the
     * filters into blocks of matches and then reply the whole block
     * into ascending order without the resetting. That'd probably
     * work better if the disk was very, very slow and we didn't have
     * any kind of disk caching. But with disk caching its about twice
     * as fast to collect each filter one by one like this. And it uses
     * less memory because there isn't a need to buffer a block of matches.
     * And its a hell of a lot less code.
     */
    private void collectSubs(AggregationExecutionContext aggCtx, Bits live, LeafBucketCollector sub) throws IOException {
        class MatchCollector implements LeafCollector {