### Description

It'd be lovely is a `filters` or `filter` agg that touches a `constant_keyword` would properly rewrite itself to `match_all` and `match_none` and "go fast", at least when it's at the root of the aggs tree. Theoretically it should "just work" but it doesn't seem to. Also! The `terms` agg should be able to act on there being only a single possible value. Maybe it can even act on the `match_all`/`match_none` nature of the `constant_keyword`. I'm not sure how, but it does feel like there are optimizations in there. Particularly when `terms` is the top level agg.
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