Add inter-query concurrency for knnPerfTest.py

[abernardi597]

I implemented inter-query concurrency by adding a new thread pool for dispatching queries to the IndexSearcher.

To do so, I made the VectorReader use random reads on its FileChannel to make the object thread-safe.

There are some other small refactors as well.

Closes #505.

[mikemccand]

Thanks @abernardi597! Sorry for the long delay ...

I left a bunch of comments. Net/net I like the change, and this is a badly needed feature, but can we find a way to not add the two new allocations (buffers/arrays) for every doc we index? I think today we reuse a single byte[] or float[] array and ByteBuffer. I like to brutally minimize any "outside of Lucene" cost so that we (as best we can) measure specifically Lucene's cost. I like that the generics for VectorReader simplified some code, but I don't like the added cost, spook methods like interpret, etc. ;)

I also suggested possible names (the hardest part) -- -numSearchThread and -numQueryThread seem like synonyms to me (searching vs querying).

I think we lost some prior code / checks (like vector files containing exactly whole vectors); I tried to catch & add comments but please double check on the deleted/refactored code that it didn't functionally lose something? Or if it's on purpose, just call it out / explain a bit.

Finally, using Java's nice async APIs ... I don't think that's really buying us much here (Lucene's internal IO itself isn't async-aware yet, I think?), and maybe losing things (prompt reporting of clear exception, and exit(1), promptly, if a query fails).

[mikemccand]

Is this in -help or so as well? Or javadocs?

[abernardi597]

I added it to the exception for misusing the flag, but not explicitly anywhere else.

[mikemccand]

Hmm is there no -help or so existing now?

[github-actions]

This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the dev@lucene.apache.org list. Thank you for your contribution!