CommonsTermsQuery with huge no. of terms slower with top-k scoring [LUCENE-9107]

In [1] a `CommonTermsQuery` is used in order to perform a query with lots of (duplicate) terms. Using a max term frequency cutoff of 0.999 for low frequency terms, the query, although big, finishes in around 2-300ms with Lucene 7.6.0.
However, when upgrading the code to Lucene 8.x, the query runs in 2-3s instead [2].
After digging a bit into it it seems that the regression in speed comes from the fact that top-k scoring introduced by default in version 8 is causing that, not sure "where" exactly in the code though.
When switching back to complete hit scoring [3], the speed goes back to the initial 2-300ms also in Lucene 8.3.x.
It'd be nice to understand the reason why this is happening and if it is only concerning `CommonTermsQuery` or affecting `BooleanQuery` as well.
If this is a case that depends on the data and application involved (Anserini in this case), the application should handle it, otherwise if it is a regression/bug in Lucene it'd be nice to fix it.

[1] : https://github.com/tteofili/Anserini-embeddings/blob/nnsearch/src/main/java/io/anserini/embeddings/nn/fw/FakeWordsRunner.java
[2] : https://github.com/castorini/anserini/blob/master/src/main/java/io/anserini/analysis/vectors/ApproximateNearestNeighborEval.java
[3] : https://github.com/tteofili/anserini/blob/ann-paper-reproduce/src/main/java/io/anserini/analysis/vectors/ApproximateNearestNeighborEval.java#L174


---
Migrated from [LUCENE-9107](https://issues.apache.org/jira/browse/LUCENE-9107) by Tommaso Teofili (@tteofili), updated Aug 07 2020
Attachments: [image-2020-08-07-16-54-27-905.png](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-9107/image-2020-08-07-16-54-27-905.png), [Screenshot 2020-08-07 at 16.20.01.png](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-9107/Screenshot%202020-08-07%20at%2016.20.01.png), [Screenshot 2020-08-07 at 16.20.05.png](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-9107/Screenshot%202020-08-07%20at%2016.20.05.png)

Start by reproducing the Lucene 7.6.0 versus 8.x timing difference using the referenced Anserini entry points: FakeWordsRunner.java and ApproximateNearestNeighborEval.java. Compare top-k scoring with complete hit scoring for CommonTermsQuery, then check whether BooleanQuery shows the same behavior. Done means the cause and affected query types are established, with a focused regression test and an agreed fix or documented application-level limitation.

Written by the indexing model from the issue text.