This PR is currently split in two commits, and the TL;DR is that this vastly improves rename detection performance for 'move without change' scenarios.
The first one extracts the code related to the label find_best_matches in git_diff_find_similar to a separate function. This should have zero behavioural changes.
The second commit add a round of cheaper exact matching before doing the existing inexact matching. The exact matching relies on comparing OIDs, and ignores opts->rename_limit since it's really cheap to run. Without having inspected the git CLI code, this seems to be the same behaviour. At the very least, it's able to find more renames than any numeric parameter provided in. Inexact matching still respects the limit though.
However, due to these changes, moving large amounts of files around are now correctly detected as renamed files. A user of Gittyup was pointing to https://codeberg.org/ArkyonVeil/HarkiusWars.Relic.Update/src/branch/GitStresser as a problematic repo demonstrating slow operations. This contains 4k+ files that are unchanged, but moved. Before, only opts->rename_limit number of renames were recognised, with the rest being add+delete pairs. With this fix, all 4k+ renames are recognised as such. On my machine running blame on any of these files has a 1000x performance improvement (~16ms instead of ~16 seconds).
Relates to #3027