Bug#26758939 : Post push fix

Updated ClusterJ testcase to expect the updated error message

(cherry picked from commit 3a94f9769c793840fd85824dbab0df166b37e36e)

Bug#26779650 - LONG SEMAPHORE WAIT CAUSED BY DROP TABLE

This is due to the for-loop in btr_drop_ahi_for_table() will skip
pages of status BUF_IO_WRITE, and re-check it again later. But there
are some other reasons the status can't be changed to BUF_IO_NONE quickly.
Thus it continues to iterate over LRU list over and over. This may
last for severl seconds or even minutes.

Current fix is to relax the condition to drop AHI for pages of
BUF_IO_WRITE too, and it will yield for a while after every iteration
over all LRU lists.

Reviewed-by: Jimmy Yang <[email protected]>

BUG#26137159 SLAVE STOPS WITH HA_ERR_KEY_NOT_FOUND (1032) WHEN PARTIT…

…IONING + INDEX USED

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.

BUG#26321303: Fix of patch

(cherry picked from commit 2c2d214a05cbbc25f74623771c55a52de4a2a2a8)