This is a regression from the fix of bug no 22176604. In this fix,
the null_row property of the TABLE object was cleared after each
iteration of the nested loops join. However, it was missed that eq_ref
access method relied on TABLE status to properly cache rows between
two accesses. And since setting a null_row status is destructive
(the NULL value vector is overwritten), we might erroneously cache
rows that had been nulled during the last access.

This is a minimal fix that solves the problem by disabling caching
of rows when used on the inner side of an outer join.

This corresponds to a minor performance regression in cases where:
- there is an inner table of an outer join that is looked up using
  a primary key or a not null unique key, and
- there are two consecutive lookups into this table with the same key.
The regressions causes us to perform an extra index dive, instead of
copying the row from the record[1] buffer.