TO SPEED UP SEQUENTIAL INSERTS

This is a regression from the fix of
Bug#16852278 SIMPLIFY RECORD COMPARISONS
which removed the n_bytes fields from the adaptive hash index.

For certain workloads, such as LOAD DATA INFILE of sorted data,
the ability of the adaptive hash index to build indexes on
byte prefixes of arbitrary binary fields is essential.
In the reported test case, there is an integer primary key,
and we end up building adaptive hash indexes on the
most significant bytes of this key.

This patch will bring back the n_bytes fields by introducing
variants of the low-level functions.
The whole-field comparison functions will be left unchanged.

btr_cur_t: Bring back up_bytes, low_bytes.
btr_search_t: Bring back n_bytes.
buf_block_t: Bring back n_bytes, curr_n_bytes.

dtuple_fold(), rec_fold(), btr_search_build_page_hash_index():
Bring back n_bytes.

page_cur_search_with_match_bytes():
A variant of page_cur_search_with_match().

cmp_dtuple_rec_with_match_bytes():
A variant of cmp_dtuple_rec_with_match().

page_cur_try_search_shortcut_bytes():
A variant of page_cur_try_search_shortcut().

ut_pair_min(), ut_pair_cmp(): Bring back these.

cmp_get_pad_char(): Bring back this.
It was previously called dtype_get_pad_char().

RB: 8961
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
Reviewed-by: Krunal Bauskar <krunal.bauskar@oracle.com>