### 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
return null;
            }
            return result;
        }
    }
    /**
     * Count of segments with "live" docs. This is both deleted docs and
     * docs covered by field level security.
     */
    private int segmentsWithDeletedDocs;
    /**
     * Count of segments with documents have consult the {@code doc_count}
     * field.
     */
    private int segmentsWithDocCountField;
    /**
     * Count of segments this aggregator performed a document by document
     * collection for. We have to collect when there are sub-aggregations
     * and it disables some optimizations we can make while just counting.
     */
    private int segmentsCollected;
    /**
     * Count of segments this aggregator counted. We can count when there
     * aren't any sub-aggregators and we have some counting optimizations
     * that don't apply to document by document collections.
     * <p>
     * But the "fallback" for counting when we don't have a fancy optimization
     * is to perform document by document collection and increment a counter
     * on each document. This fallback does not increment the
     * {@link #segmentsCollected} counter and <strong>does</strong> increment