feat: Add Chebyshev distance (L_∞ norm) support

[cbueth]

This is a PR #286, reopened for the fitting branch. I rebased my suggested changes, dropping all other commits. Locally all test still pass. I have added a few cases to increase code coverage. Find the PR description over at #286. I will just add onto. it here.

For the default implementation of accumulate I understood best to use num_traits::SaturatingAdd, but this trait is only implemented for integer types, not for floating-point types (f32, f64). So now I changed it to use std::ops::Add as the bound, which works for both integers and floats. This means the default rd + delta works correctly for floating-point types (produces inf on overflow), but fixed-point types need to override accumulate with rd.saturating_add(delta) to prevent overflow. I ignorantly assume that this covers a larger userbase and think this solution is the best we can do without specialization (is currently unstable https://std-dev-guide.rust-lang.org/policy/specialization.html / rust-lang/rust#31844). To my understanding this is still a breaking change for users with fixed-point types who implement custom DistanceMetrics. The only feasible alternative I see would be with a macro to generate implementations that can differentiate the two. Please correct me if I got this wrong.

Secondly, I want to clarify a statement from my previous #286 (comment).

• Finally, I was not able to find a test where < vs <= makes a difference, but programmatically I agree it could strictly be the right choice. As of now I changed some back to <. You can see the two places it was added (D::IS_MAX_BASED removed in this commit c934656. NON_STRICT_PRUNING would be a better name). I'd suggest you treat this as a separate issue.

I was only not able to find a relevant test where the <= removed in c934656 did (dist_belongs_in_heap) make a difference, so I changed them to <. But still, there are other occurences that are still included and that did make a difference in the test with gaussian data. So if you think there are some cases where having the <= for dist_belongs_in_heap, these can be re-added. Right now there are many parametrizes test cases with nearest_n, but not for within.

If there are suggestions for changes, don't heasitate to say so.

Closes #286

[sdd]

Hi again Carlson! Just seen this, I will check them out over the next day or two. Thanks!

[codecov]

Codecov Report

❌ Patch coverage is 95.53719% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.03%. Comparing base (f87b965) to head (7adffe8).

Files with missing lines	Patch %	Lines
src/traits.rs	29.41%	12 Missing ⚠️
src/float/distance.rs	98.21%	3 Missing and 5 partials ⚠️
src/fixed/distance.rs	93.69%	5 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           v5.x.x     #290      +/-   ##
==========================================
+ Coverage   94.89%   95.03%   +0.13%     
==========================================
  Files          54       54              
  Lines        5685     6264     +579     
  Branches     5685     6264     +579     
==========================================
+ Hits         5395     5953     +558     
- Misses        273      287      +14     
- Partials       17       24       +7     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cbueth]

Sounds good, thanks :)
Let me know of last changes you want me to integrate, e.g. coverage, formatting.

[sdd]

Thanks. As it is, the commit lint step fails because some of your commit message subjects are not confirming to Conventional Commits standard. You can either fix them individually with interactive rebase, or squash them into one commit with a catch-all subject like feat: Add Chebyshev distance metric