cmp_rec_rec() unnecessarily depends on rec_get_offsets()

The function rec_get_offsets() was introduced by me in MySQL 5.0.3 along with ROW_FORMAT=COMPACT, which reduces the size of ENGINE=InnoDB records by making record headers only include information about variable-length records. This complicated the access to individual fields in index records. In the original format that was renamed to ROW_FORMAT=REDUNDANT at that point, the record header includes a pointer to the end of each field in the record. All of those pointers are 8 or 16 bits wide, indicated by a flag in the fixed part of the record header.

The initial prototype of the new format may have included an accessor function that would iterate the record header to find an offset to the requested field. This would clearly become a performance bottleneck, because individual fields were repeatedly accessed from quite a few places. So, the cache rec_get_offsets() was born. This cache always was a stop-gap measure. It causes additional memory consumption that could be avoided.

MDEV-12353 eliminated some redundant rec_get_offsets() from code paths that insert records, as well as completely eliminated it from the crash recovery logic.

MDEV-35049 eliminated the rec_get_offsets() from some operations. Most notably, rec_fold() (for computing adaptive hash index values) and the comparison page_cur_dtuple_cmp() between index records and search tuples would determine the start offset of each field on the fly.

In MDEV-32067, we are mostly eliminating the need for rec_get_offsets() for accessing the child page number in a record pointer.

After those changes, we still have the function cmp_rec_rec() depending on rec_get_offsets(). Most of its callers, with the exception of PageStats::scan() (refactored in MDEV-19574), would allocate the offsets from stack and/or the heap, and spend time in computing the offsets. I think that we should mimic page_cur_dtuple_cmp() in cmp_rec_rec() and let it find the start and length of each field on the fly. This should be straightforward, because the function is comparing the two index records one field at a time.