Currently, some unit tests fail because recalls of them are smaller than the threshold.

TODO:

• hash table
• mottainai bit

Fixed the low recall problem and did the to-do things but found that this update is not necessary to implement the RAFT RNN benchmark for CAGRA (:cry:). However, I will proceed with this PR to ensure the completeness of the index data type.
(In the current mainstream implementation, some compilation errors occur when specifying uint64_t as the index data type. This PR address them.)

@tfeher Can you check the code and let me know if there are any problems?

Thanks @enp1s0 for this PR! I think it is very useful to update the code to work with other index type (even if we would mainly use with 32bit indices). I will have a look at the changes.

Thanks @tfeher for reviewing the changes.

it would be sufficient to test limited template type combinations in int64 mode?

Yes, I agree with you. I'll remove the (DataT, IdxT) = (int8, uint64) and (uint8, uint64) tests.

@tfeher I have a question about supporting signed 64-bit int (int64_t) as the index data type.
Currently, int64_t does not work as expected, with the recall becoming zero when using it. I'm not sure of the cause, but some parts of the current CAGRA kernels assume the index data type is unsigned. While it is true that the index is always positive, I understand that it is preferred to support signed data types to have freedom in the index data types.

While it is possible to modify the kernels to support int64_t and make them work as expected, I prefer an alternative approach: using kernel functions designed for unsigned index data types and using reinterpret_cast to treat the signed types as unsigned. The advantages of this implementation are as follows:

1. We can use the same kernel functions for both signed and unsigned index types, which helps to keep the binary size of the library from increasing.
2. We can avoid the need for additional out-of-range memory access checks for signed types.

This implementation should not have any disadvantages because, if the data type is signed, the index is always positive, and the range of representation for unsigned types is larger than that of signed types.

What do you think about it?

using kernel functions designed for unsigned index data types and using reinterpret_cast to treat the signed types as unsigned

This sounds good to me!

@tfeher I have fixed the codes! Can you look at them again?

/merge