### Description

Min/Max aggregations do not require any scaling for the random_sampler results. Additionally, if the min/max an be determined via the pointReader (i.e. not by individual doc values), we should use that as it means that sampler doesn't need to supply documents to the min/max agg, potentially speeding things up significantly and improving accuracy.

related to: https://github.com/elastic/elasticsearch/issues/84353
server/src/main/java/org/elasticsearch/search/aggregations/AggregatorBase.java
*/
    @Override
    public ScoreMode scoreMode() {
        for (Aggregator agg : subAggregators) {
            if (agg.scoreMode().needsScores()) {
                return ScoreMode.COMPLETE;
            }
        }
        return ScoreMode.COMPLETE_NO_SCORES;
    }
    public Map<String, Object> metadata() {
        return this.metadata;
    }
    /**
     * Collect results for this leaf.
     * <p>
     * Most {@linkplain Aggregator}s will return a custom
     * {@link LeafBucketCollector} that collects document information for
     * every hit. Callers of this method will make sure to call
     * {@link LeafBucketCollector#collect(int, long) collect} for every hit. So any
     * {@link Aggregator} that returns a customer {@linkplain LeafBucketCollector}
     * from this method runs at best {@code O(hits)} time. See the
     * {@link SumAggregator#getLeafCollector(LeafReaderContext, LeafBucketCollector) sum}
     * {@linkplain Aggregator} for a fairly strait forward example of this.
     * <p>
     * Some {@linkplain Aggregator}s are able to correctly collect results on
     * their own, without being iterated by the top level query or the rest
     * of the aggregations framework. These aggregations collect what they
     * need by calling methods on {@link LeafReaderContext} and then they
     * return {@link LeafBucketCollector#NO_OP_COLLECTOR} to signal that they've