Problem:
When table partitions and indexes are used simultaneously, and the index
key is not in the partition function, in some situations replication
would stop because a given key could not be found when executing an
update or delete statement. This issue only happened when
slave-rows-search-algorithms is set to hash_scan.

Analysis:
When slave-rows-search-algorithms is set to hash_scan, the applier
searches for keys(hashes) of the rows that will be modified. Since in
this case, the index key was not in the partition function, the
retrieved rows could not always be a match. If the key to the retrieved
row happened to be different than the key currently being searched, we
would advance to the next key, even if not all rows up to that key had
been retrieved yet.

Fix:
Advance to the next key to search (or return an error) only when the
search for a given key value ends without finding the corresponding key,
instead of advancing to the next key when the index key is different
than the key being searched.

(cherry picked from commit 8fefcc056b7dd704bf381788f9ab52cbcd0d41af)