### Elasticsearch Version

8.3.0

### Installed Plugins

_No response_

### Java Version

_bundled_

### OS Version

All

### Problem Description

In `rest-api-spec/test/analytics/nested_top_metrics_sort.yml` there are the following two tests:

* `terms order by top metrics size greater than 1 rewrite_to_filter_by_filter false`
* `terms order by top metrics size greater than 1 rewrite_to_filter_by_filter true`

Both tests execute the same query. The only difference is in the setting of `rewrite_to_filter_by_filter`, in one case it is `true` in the other it is `false`. The setting determines if the query is rewritten using the so called "filter by filter" optimisation. Query rewriting is an implementation detail and we should make sure the response provided to the client is the same no matter the value of the setting.

Here one query fails with an exception while the other not. We need to make sure the result is the same. We either fail both or we return the same aggregation result.

NOTE: right now the test is not failing because they are written in such a way to highlight the difference. After fixing the issue we expect to have the same result.

### Steps to Reproduce

Just execute the YAML tests.

### Logs (if relevant)

_No response_
x-pack/plugin/analytics/src/test/java/org/elasticsearch/xpack/analytics/topmetrics/TopMetricsAggregatorTests.java
assertThat(indexReader.leaves(), hasSize(1));
                LeafBucketCollector leaf = aggregator.getLeafCollector(
                    new AggregationExecutionContext(indexReader.leaves().get(0), null, null, null)
                );
                /*
                 * Collect some number of buckets that we *know* fit in the
                 * breaker. The number of buckets feels fairly arbitrary but
                 * it comes from:
                 * budget = 15k = 20k - 5k for the "default weight" of ever agg
                 * The 646th bucket causes a resize which requests puts the total
                 * just over 15k. This works out to more like 190 bits per bucket
                 * when we're fairly sure this should take about 129 bits per
                 * bucket. The difference is because, for arrays in of this size,
                 * BigArrays allocates the new array before freeing the old one.
                 * That causes us to trip when we're about 2/3 of the way to the
                 * limit. And 2/3 of 190 is 126. Which is pretty much what we
                 * expect. Sort of.
                 */
                int bucketThatBreaks = 646;
                for (int b = 0; b < bucketThatBreaks; b++) {
                    try {
                        leaf.collect(0, b);
                    } catch (CircuitBreakingException e) {
                        throw new AssertionError("Unexpected circuit break at [" + b + "]. Expected at [" + bucketThatBreaks + "]", e);
                    }
                }
                CircuitBreakingException e = expectThrows(CircuitBreakingException.class, () -> leaf.collect(0, bucketThatBreaks));
                assertThat(e.getMessage(), equalTo("test error"));
                assertThat(e.getByteLimit(), equalTo(max.getBytes()));
                assertThat(e.getBytesWanted(), equalTo(5872L));