Fix terms aggregation doc_count_error_upper_bound for already reduced results (batched query phase)

[benchaplin]

There's logic in AbstractInternalTerms that sets the top-level doc_count_error_upper_bound to 0 if only one aggregation is being reduced. However, now that we have batched query execution, it's possible a reduction of multiple aggregations has already occurred on a data node, and is now undergoing a final reduction on the coordinating node.

I discovered this case while attempting to remove the settings override turning off batched query execution in TermsDocCountErrorIT (testFixedDocs with -Dtests.seed=ABFC03388645940D):

• 3 shards on a data node, 0 shards on the coordinating node
• batched request performs partial reductions on the data node, calculating the expected value of doc_count_error_upper_bound = 46
• coordinating node attempts the final reduction, but since its reducing only one agg, sets the doc_count_error_upper_bound to 0

I've attempted a lightweight fix here: flag the existence of a batched query result in the AggregationReduceContext, then check this flag when potentially setting doc_count_error_upper_bound to 0. If a batched query result is present, it implies multiple shards were reduced remotely (a single shard on a data node is not batched).

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[elasticsearchmachine]

Pinging @elastic/es-search-foundations (Team:Search Foundations)