New patch attached.
I added Koji's test as a unit test, that fails on trunk but passes now
with the patch.
The new scorer is definitely slower if you do want scoring, however,
it's actually uncommon for this scorer to be used... because BQ will
use BS when the query is all SHOULD clauses (plus up to 32 NOT).
Only if there is also 1 or more MUST clauses will this scorer be used,
or, if the collector does not support out-of-order scoring. I had to
hack BQ to temporarily turn off BS to test this.
Insanely, the constant score BQ rewrite does use this scorer, because
when ConstantScorer invokes the sub-scorer it requires in-order
scoring. So ConstantScoreQuery and constant score BQ rewrite for the
MTQs will always see the speedup from this patch.
So given that it's rare to actually use the scorer, I think ~8% gain
as seen by "default" usage makes it worthwhile net/net.
Longer term... we should probably change the Weight.scorer API so that
you notify it up-front if you need to do scoring. This way
we can specialize (manually or automatically) the best class, instead
of waiting to see whether the .score() method is invoked per hit.