Do not reset the value of the item_equal field in the Item_field object
once it has been set.

Address Monty's review comments

Added item.real_type() for easy access to the underlaying types for Item_ref and Item_cache_wrapper()
This allows us to simplify and speed up some tests and also remove get_cached_item()

sql/item.h:
  Added item.real_type()
  Removed get_cached_item()
sql/opt_range.cc:
  Simplify test
sql/sql_select.cc:
  Simplify test
sql/sql_show.cc:
  Simplify test

Analysis:
The assert failed because the execution code for
partial matching is designed with the assumption that
NULLs on the left side are detected as early as possible,
and a NULL result is returned before any lookups are
performed at all.

However, in the case of an Item_cache object on the left
side, null was not detected properly, because detection
was done via Item::is_null(), which is not implemented at
all for Item_cache, and resolved to the default Item::is_null()
which always returns FALSE.

Solution:
Use the property Item::null_value instead of is_null(), which
is properly updated for Item_cache objects as well.

Don't check if LAST_IO_Error has changed as this is not a user variable and it may change depending on timing issues between master and slave

If join condition is of the form <t2.key>=<t1.no_key> then the server
performs no index look-ups when looking for matching rows of t2 for
the rows from t1 with t1.no_key=NULL. It happens because the function
add_not_null_conds() injects an additional condition of the form 
IS NOT NULL(<t1.no_key>) into the WHERE condition.
However if the join condition was of the form <t.key>=<outer_ref> no
additional null rejecting predicate was generated. This could lead
to extra records in the result set if the value of <outer_ref> happened
to be NULL.
The new code injects null rejecting predicates of the form 
IS NOT NULL(<outer_ref>) and evaluates them before the first row
the subquery is constructed.

Generally, we should use only small letters for table names 
but here it's easier to fix with one --replace.

- cleaner code
- ability to change from using pointers to offsets at some point

- The problem was that Mrr_ordered_index_reader's interrupt_read() and resume_read() would 
  save and restore 1) index tuple  2) the rowid (as bytes returned by handler->position()).  Clustered 
  primary key columns were not saved/restored. 
  They are not explicitly present in the index tuple (i.e. table->key_info[secondary_key].key_parts 
  doesn't list them), but they are actually there, in particular 
  table->field[clustered_primary_key_member].part_of_key(secondary_key) == 1. Index condition pushdown
  code [correctly] uses the latter as inidication that pushed index condition can refer to clustered PK
  members. 

  The fix was to make interrupt_read()/resume_read() to save/restore clustered primary key members as well,
  so that we get correct values for them when evaluating pushed index condition.
[3rd attempt: remove the debugging aids, fix comments in testcase]

Analysis:
The reason for the crash was that the inner subquery was executed
via a scan on a final temporary table applied after all other
operations. This final operation is implemented by changing the
contents of the JOIN object of the subquery to represent a table
scan over the temp table. At the same time query optimization of
the outer subquery required evaluation of the inner subquery, which
happened before the actual EXPLAIN. The evaluation left the JOIN
object of the inner subquery in the changed state, where it represented
a table scan over a temp table, and EXPLAIN crashed because the temp
table is not associated with any table reference (TABLE_LIST object).
The reason the JOIN was not restored was because its saving/restoration
was controlled by the join->select_lex->uncacheable flag, which was
not set in the case of materialization.

Solution:
In the methods Item_in_subselect::[single | row]_value_transformer() set:
    select_lex->uncacheable|= UNCACHEABLE_EXPLAIN;
In addition, for symmetry, change:
    master_unit->uncacheable|= UNCACHEABLE_EXPLAIN;
instead of UNCACHEABLE_DEPENDENT because if a subquery was not
dependent initially, the changed methods do not change this
fact. The subquery may later become correlated if it is transformed
to an EXISTS query, but it may stay uncorrelated if executed via
materialization.

- Make DsMrr_impl::dsmrr_init() handle the case of 
   1. 1st MRR scan using DS-MRR strategy (i.e. doing key sorting and rowid sorting)
   2. 2nd MRR scan getting a buffer that's too small to fit one key element 
      and one rowid element, and so falling back to default MRR implementation
  In this case, dsmrr_init() is invoked with {primary_handler, secondary_handler}
  initialized for DS-MRR scan and have to reset them to be initialized for the
  default MRR scan.
(attempt 2, with simplified testcase)