remove hard limit on the number of items returned when an index is queried

[ezra-varady]

This should address #74 It includes a regression test where ...LIMIT 10 (the new default) and ...LIMIT 50 are tested.

Resolves #74

[ezra-varady]

to summarize,

• I fixed the issue with the static variable. You're absolutely right about it breaking when two queries occur simultaneously. An embarrassing mistake.
• Moved new tests into hnsw.sql and made corresponding updates to the expected output
• Added debug logging of init_k when usearch_search is called, as well as tests that modify it

I still need to add a test for the query being bigger than the table. Since LIMIT only imposes an upper bound I'm not totally sure how to induce this actually, but I'll work on it this afternoon. The case of k greater than the limit is tested and behaves correctly.

[Ngalstyan4]

Thanks for the prompt fixes, @ezra-varady!

I still need to add a test for the query being bigger than the table.

I am not sure what you want to test here. But if the problem is that the table has more rows than you need, you can place the test in a transaction, drop all the extra rows in the transaction, then run the query, then rollback the transaction. See an example of this kind of thing here.

Note that you also do not need a large table to force index usage in tests. you can just disable sequential scan.

[ezra-varady]

Thanks, I didn't know that! I reformatted the tests in light of this. I also added a check to avoid a potential extra query I had neglected. I think I had misunderstood your suggestion w.r.t. the additional test. Please let me know if you have other suggestions

[ezra-varady]

removed the hanging comment and changed the log level for the tests