SearchThresholdAdjustingQueryRunner and TopNQueryQueryToolChest.ThresholdAdjustingQueryRunner sanity

Those classes don't make sense to me. E. g. with TopN, whether the query threshold is 3 or 300 or 3000, it always could make sense to have per-historical / per-segment threshold (is this what is meant by "minTopNThreshold", right?) of 1000. They are independent. Also it's really hard to understand how the manipulation happens across broker/historical boundary, because within a Historical it's a wastful no-op (extend the threshold and then trim the results again).

For `SearchThresholdAdjustingQueryRunner`, `Iterables.limit()` modification is a no-op (because `query.getLimit()` is bigger than `config.getMaxSearchLimit()`).

@gianm @drcrallen

Start by reading SearchThresholdAdjustingQueryRunner and TopNQueryQueryToolChest.ThresholdAdjustingQueryRunner, focusing on Iterables.limit(), query.getLimit(), config.getMaxSearchLimit(), and minTopNThreshold. Trace how thresholds are changed across broker and historical boundaries, then determine the intended behavior and whether the reported no-op or redundant trimming needs a correction.

Written by the indexing model from the issue text.