Bug#30922503 MULTI-TABLE UPDATE NOT RESPECTING VIEW'S CHECK OPTION

Due to optimizations done in JOIN::optimize() (optimize_cond()), a
multi-table UPDATE sometimes mangles the CHECK OPTION of a view, and the
result is that this clause is no longer checking what it should, and thus
the UPDATE updates rows which it shouldn't.
The mangling is explained in edited comments in sql_update.cc.
Single-table UPDATE properly reports an error instead.

Fix: use the existing mechanism Item::set_no_const_sub(). It was, so far,
dependent on the collation; this dependency is moved up into the caller,
so that set_no_const_sub() just sets the property.

Also, rewrote the code in single-table UPDATE to use that mechanism too,
and then dock into optimize_cond(), instead of explicitly invoking
only the safe parts of optimize_cond() (those which don't do equality
propagation). With the no_const_sub marks, the entire optimize_cond()
becomes safe, as Item_field::equal_fields_propagator() does
nothing then. This is an improvement, as it allows equality
propagation in parts of WHERE which are not coming from CHECK OPTION.
In Item_field::cleanup(), added a resetting of no_const_subst.
This is good practice for a property set by code which is
re-executed at each preparation or optimization of the statement,
as no_const_subst is. It allows that code to take different
decisions in different preparations (though it won't happen in our case).

Item::no_const_subs is renamed to no_constant_propagation,
Item::set_no_const_sub is renamed to disable_constant_propagation.

Change-Id: I8833868561ea08b229185cb53e98c14932a04242