### 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
*/
    @Override
    protected LeafBucketCollector getLeafCollector(AggregationExecutionContext aggCtx, LeafBucketCollector sub) throws IOException {
        assert scoreMode().needsScores() == false;
        if (QueryToFilterAdapter.MatchesNoDocs(filters())) {
            return LeafBucketCollector.NO_OP_COLLECTOR;
        }
        Bits live = aggCtx.getLeafReaderContext().reader().getLiveDocs();
        if (live != null) {
            segmentsWithDeletedDocs++;
        }
        if (false == docCountProvider.alwaysOne()) {
            segmentsWithDocCountField++;
        }
        if (subAggregators.length == 0) {
            
            /*
             * Without sub.isNoop we always end up in the `collectXXX` modes even if
             * the sub-aggregators opt out of traditional collection.
             */
            segmentsCounted++;
            collectCount(aggCtx.getLeafReaderContext(), live);
        } else {
            segmentsCollected++;
            collectSubs(aggCtx, live, sub);
        }
        return LeafBucketCollector.NO_OP_COLLECTOR;
    }
    /**
     * Gather a count of the number of documents that match each filter