Incorrectly implemented `common_prefix_len`

[mzabaluev]

Describe the bug
The optimized helper function for finding the common prefix length is incorrect.

To Reproduce

1. Add this test to sort_exec.rs:

    #[test]
    fn has_common_prefix_len_been_optimized_into_bogusness() {
        let cpl = common_prefix_len(&[0; 8], &[0; 8]);
        assert_eq!(cpl, 8);
        let cpl = common_prefix_len(&[0; 4], &[0; 4]);
        assert_eq!(cpl, 4);
        let cpl = common_prefix_len(&[0; 2], &[0; 2]);
        assert_eq!(cpl, 2);
        let cpl = common_prefix_len(&[0; 1], &[0; 1]);
        assert_eq!(cpl, 1);
    }

2. Run the test.

Proposed fix
Change the < min_len comparisons to <= min_len.

Or just replace with a simple implementation and benchmark if the tweaky one really improves perf, e.g.:

fn common_prefix_len(a: &[u8], b: &[u8]) -> usize {
    std::iter::zip(a, b).take_while(|(&x, &y)| x == y).count()
}

[richox]

yes, the condition should be changed to <= min_len. luckily the smaller lcp value will not cause inconsistent output.
This optimization is effective on most CPUs and has been widely used in various compression libs like snappy.

[mzabaluev]

There may be another happy path alternative for the primary loop: if both pointers happen to be aligned to 8 (as they would be if the offset of a slice in the key buffer is 0), you could perform aligned reads into u64. But this needs to be profiled on realistic workloads, as too many branches may degrade performance for small inputs.

[richox]

There may be another happy path alternative for the primary loop: if both pointers happen to be aligned to 8 (as they would be if the offset of a slice in the key buffer is 0), you could perform aligned reads into u64. But this needs to be profiled on realistic workloads, as too many branches may degrade performance for small inputs.

this function performs on arrow-row data, which is not aligned and in many cases the bytes length is variable, so i dont think there is a happy path.