Add FloatArray interface to allow easy float[] vector extraction from MemorySegmentVectorFloat and ArrayVectorFloat instances

[reta]

Add FloatArray interface to allow easy float[] vector extraction from MemorySegmentVectorFloat and ArrayVectorFloat instances. It solves the problem that we have to:

• use explicit typecast to known types (float[], MemorySegment) to figure out what kind of the holder object VectorFloat has
• deal with reflection (MemorySegment available in JDK-22 but OpenSearch baseline is JDK-21) or per-element access semantics which is inefficient

The suggestion is to introduce new FloatArray interface to have a fast track float[] array conversion for VectorFloats that support it. The change is 100% non-breaking.

Closes #696

[github-actions]

Before you submit for review:

• Does your PR follow guidelines from CONTRIBUTIONS.md?
• Did you summarize what this PR does clearly and concisely?
• Did you include performance data for changes which may be performance impacting?
• Did you include useful docs for any user-facing changes or features?
• Did you include useful javadocs for developer oriented changes, explaining new concepts or key changes?
• Did you rebase your branch onto the latest main for regression testing and PR submission?
• Did you trigger regression testing via Run Bench Main and review results?
• Did you adhere to the code formatting guidelines (TBD)
• Did you group your changes for easy review, providing meaningful descriptions for each commit?
• Did you ensure that all files contain the correct copyright header?
• Did you add documentation for this feature to the release notes directory?

If you did not complete any of these, then please explain below.

[r-devulap]

Curious about the need for introducing a separate FloatArray interface here. Could we instead add an abstract method on VectorFloat<?> itself similar to the array() method introduced in this PR and require implementations like ArrayVectorFloat and MemorySegmentVectorFloat to provide it? That seems like it might keep the API simpler by avoiding an extra type just for array extraction.

[reta]

Curious about the need for introducing a separate FloatArray interface here. Could we instead add an abstract method on VectorFloat<?> itself similar to the array() method introduced in this PR and require implementations like ArrayVectorFloat and MemorySegmentVectorFloat to provide it?

If we don't care about compatibility much (since this classes are public and if by chance there are implementations outside the library), than yes - we could certainly do that. It will definitely make the pull request simpler.

What we could do is to get rid of FloatArray is something like that (that would not break compatibility):

default float[] array() {
    throw new UnsupportedOperationException();
}

But again, if compatibility is not a concern - we could get rid of FloatArray, thanks @r-devulap !

[r-devulap]

I will let @ashkrisk weigh in on it, he is more qualified to answer that :)

[ashkrisk]

While there are legitimate, performance related reasons to want direct access to the underlying float[] store, the API as it stands is not designed with that in mind. IMO either of the proposed approaches breaks the encapsulation of the VectorFloat interface in potentially undesirable ways.

At the moment I can only see one place where Opensearch accesses the underlying array. Another solution that might work here would be to add a toArray() method that works on all VectorFloat types and returns a copy of its underlying data.

@reta can you open an issue explaining your use-case in more detail? With more information we can figure out what the best solution is.

[reta]

While there are legitimate, performance related reasons to want direct access to the underlying float[] store, the API as it stands is not designed with that in mind. IMO either of the proposed approaches breaks the encapsulation of the VectorFloat interface in potentially undesirable ways.

@ashkrisk this is exactly the reason why VectorFloat is not changed, there is a new interface that adds this functionality to implementing classes that could be implemented.

@reta can you open an issue explaining your use-case in more detail? With more information we can figure out what the best solution is.

See please this pull request https://github.com/opensearch-project/opensearch-jvector/pull/507/changes#diff-ddf73468c0184ab1f6ef7973480de2cbdf98d8eb63d0aec938ec4dd6b5d6e73cR153

[reta]

At the moment I can only see one place where Opensearch accesses the underlying array. Another solution that might work here would be to add a toArray() method that works on all VectorFloat types and returns a copy of its underlying data.

@ashkrisk exploring your idea here #697, thanks!