Fix potential NPE for KnnVectorQuery

[benwtrent]

When using a particular leaf reader (possibly for a MemoryIndex), parent can be null.

Let's verify that and prevent an NPE

[github-actions]

This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR.

[jainankitk]

I am assuming the same reasoning applies here as well? // ctx.parent could be null if this is a MemoryIndex. If yes, can be add the comment here as well?

[msokolov]

If this is a real problem, why hasn't it surfaced in unit test failures? Or ... maybe it did?

[benwtrent]

@msokolov I am not sure, I noticed it in ES:

elastic/elasticsearch#136427

Maybe we just exit early there (which I think we will do, e.g. InMemoryIndex just cannot have kNN happen), but it seems to me better to fix it here as well.

[msokolov]

I guess what I'm wondering is does this point a testing gap in Lucene? I thought that we would randomize the index directory type when running tests ...

[benwtrent]

Looking at MemoryIndex:

    @Override
    public void searchNearestVectors(
        String field, float[] target, KnnCollector knnCollector, AcceptDocs acceptDocs) {}

    @Override
    public void searchNearestVectors(
        String field, byte[] target, KnnCollector knnCollector, AcceptDocs acceptDocs) {}

So, returning no hits and forcing exact (or the caller to change), is the way. But we should definitely not throw an NPE. I can add a test really quick to make sure this won't throw an NPE.