MB-60844: MapReduce for PreSearch

[CascadingRadium]

• Instead of Merging all the PreSearch Results in one shot at the main coordinator node of an alias tree, merge them incrementally at each level of the tree instead, which would balance the reduction process across all the indexes in a distributed Bleve index, leading to a more even memory distribution.

[abhinavdangeti]

Why can't return type here simply be KnnPreSearchResultProcessor? I don't really see the need for 2 structs above. We can drop PreSearchResultProcessor.

[CascadingRadium]

the aim is to allow Presearch to be generic construct that can be reused for other purposes. Lets say i have another logic for merging synonym results from multiple partitions, i would add the SynonymPreSearchResultProcessor as another struct in the PreSearchResult Processor, so any presearch result containing either knn or synonym data can be processed independently. By just keeping it as KnnPreSearchResultProcessor in PreSearchDataSearch, i would have to refactor it later on for synonym search.

[abhinavdangeti]

I understand your rationale but we can adapt this or add a separate processor for synonyms later, we'll also want to refactor the name - preSearchDataSearch at that point as well, which is quite distasteful.

For now let's reduce the number of redirects, keep it simple.

[CascadingRadium]

have made it an interface and one struct implementing it now ... cannot use it directly as the index_alias_impl.go file is not in the vectors tag so it cannot read the knn specific code like the knn store ...