Encapsulate KNNQueryBuilder creation within NeuralKNNQueryBuilder

[junqiu-lei]

Description

Centralizes KNNQueryBuilder creation in NeuralKNNQueryBuilder to:

1. Put KNNQueryBuilder in a single location for easier handle breaking change from k-NN plugin.
2. Provide abstraction for future extensions like for neural highlighter feature need the original query text as input, which is currently lost in kNNQuery object. More context can be found at "Neural Query Builder Wrapper (based on Highlighter Framework Approach)" in [RFC] OpenSearch Neural Sentence Highlighting #1175

Related Issues

Part of #1182

Check List

• New functionality includes testing.
• Commits are signed per the DCO using --signoff.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.69%. Comparing base (ebfb058) to head (45b99f4).
Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1183      +/-   ##
============================================
- Coverage     81.69%   81.69%   -0.01%     
+ Complexity     2489     1260    -1229     
============================================
  Files           186       95      -91     
  Lines          8434     4282    -4152     
  Branches       1428      717     -711     
============================================
- Hits           6890     3498    -3392     
+ Misses         1002      511     -491     
+ Partials        542      273     -269     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[martin-gaievski]

looks good to me, thanks

Need to fix bwc test failure.

[martin-gaievski]

if this change is for 3.0 we need to look into BWC 3.0 -> 2.19, that's our current strategy, support rolling upgrades to latest minor of previous major, we probably should continue doing same after 3.x will be released. Of course this makes more sense if errors in BWC are hard to fix, proper deep dive is required

[junqiu-lei]

if this change is for 3.0 we need to look into BWC 3.0 -> 2.19, that's our current strategy, support rolling upgrades to latest minor of previous major, we probably should continue doing same after 3.x will be released. Of course this makes more sense if errors in BWC are hard to fix, proper deep dive is required

Makes sense, looking into the bwc tests failure.

[junqiu-lei]

The 2.19->3.0.0 bwc test failed due to known issue #1142.