### 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
* aggregations but likely correct when "range", "date_histogram",
                 * or "terms" are converted to this agg. We investigated a sort
                 * of "combined" iteration mechanism and its complex *and* slower
                 * than the native implementations of the aggs above.
                 */
                valid = false;
                return;
            }
            if (filters.size() == 1) {
                /*
                 * When we add the second filter we check if there are any _doc_count
                 * fields and bail out of filter-by filter mode if there are. _doc_count
                 * fields are expensive to decode and the overhead of iterating per
                 * filter causes us to decode doc counts over and over again.
                 */
                if (aggCtx.hasDocCountField()) {
                    valid = false;
                    return;
                }
            }
            filters.add(mergedFilter);
        }
        /**
         * Build the the adapter or {@code null} if the this isn't a valid rewrite.
         */
        public final T build() throws IOException {
            if (false == valid) {
                return null;
            }
            class AdapterBuild implements CheckedFunction<AggregatorFactories, FilterByFilterAggregator, IOException> {