Fix usage of zim::Searcher::getResults() in libkiwix

[maneeshpm]

Fixes #595

The correct usage does not require the user to calculate an end using the pageLength. We can directly use getResults(start, pageLength)

[codecov]

Codecov Report

Merging #597 (9addd82) into master (a032d65) will decrease coverage by 0.00%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #597      +/-   ##
==========================================
- Coverage   64.79%   64.78%   -0.01%     
==========================================
  Files          53       53              
  Lines        3730     3729       -1     
  Branches     1856     1856              
==========================================
- Hits         2417     2416       -1     
  Misses       1311     1311              
  Partials        2        2              

Impacted Files	Coverage Δ
include/searcher.h	33.33% <ø> (ø)
src/searcher.cpp	47.10% <44.44%> (ø)
src/server/internalServer.cpp	83.58% <100.00%> (-0.04%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a032d65...9addd82. Read the comment docs.

[mgautierfr]

This PR is a "big" and tricky API change.
And it also change the behavior in a way that either it was buggy before or it is buggy now.

This PR change the function arguments from "two" unsigned int (start, end) to "two" other unsigned int (start, number).
So ABI is keep but the API is totally changed. It means that if we forget one call, we will not detect it at compilation and we will introduce a bug difficult to see.

On top of that, we were using getResults passing the start/end couple.
Now we are passing start/number.
But end=start+number. If start is 0, it doesn't change anything. But if we are getting result in the middle of the search, it is broken.

This change follow the semantic change of openzim/libzim#597. But it is only a semantic change. Nothing is really changed on libzim side. So we should not change things here.

So there is something wrong somewhere. I've the feeling that previous code was wrong as xapian't get_mset takes maxitem and not end (https://xapian.org/docs/apidoc/html/classXapian_1_1Enquire.html#a1f2e35f79bc731bebfbdaceda17b9892).

It would be nice to have a unit test showing that :

• Either previous code is buggy, then we add a new (failing) test in a commit and fix it in a following commit(s).
• Either this PR is buggy, then we add a new (passing) test in a commit. This commit make the test failing, and we add a new fixup! commit fixing this.

[maneeshpm]

@mgautierfr Showing that the previous code is buggy is easy on libzim side. But on libkiwix side, our SearchRenderer which takes a SearchResultSet sort of masks this issue in ft search by selecting only pageLength number of results. I was only able to discover it because of #242 where getResult(5,10) returned 10 suggestions. What kind of failing test case do you suggest?

[mgautierfr]

I was only able to discover it because of #242 where getResult(5,10) returned 15 suggestions. What kind of failing test case do you suggest?

It seems that the sentence just before the question is the answer to the question :)

[mgautierfr]

Two small change that should be easy to fix.

[mgautierfr]

Just a small change to be pedantic.
Else we are good.