### 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
private FilterByFilterAggregator agg;
                @Override
                public FilterByFilterAggregator apply(AggregatorFactories subAggregators) throws IOException {
                    agg = new FilterByFilterAggregator(
                        name,
                        subAggregators,
                        filters,
                        keyed,
                        keyedBucket,
                        aggCtx,
                        parent,
                        cardinality,
                        metadata
                    );
                    return agg;
                }
            }
            AdapterBuild adapterBuild = new AdapterBuild();
            T result = adapt(adapterBuild);
            if (adapterBuild.agg.scoreMode().needsScores()) {
                /*
                 * Filter by filter won't produce the correct results if the
                 * sub-aggregators need scores because we're not careful with how
                 * we merge filters. Right now we have to build the whole
                 * aggregation in order to know if it'll need scores or not.
                 * This means we'll build the *sub-aggs* too. Oh well.
                 */