WL#5275 removed some code from Item_direct_view_ref::fix_fields()
which was introduced by the bugfix for bug#47150, and the case for
that bug no longer failed. However, it was possible to trigger the
same bug with a similar query.

The problem may occur for multi-table UPDATE of view where the same
column is used in SET clause and JOIN clause, used as a prepared
statement. The bug does not show with JOIN ... ON, only JOIN ... USING
or NATURAL JOIN.

The problem is that we share Item_field objects underneath several
Item_direct_view_ref objects. Item_field is fixed on first use.
On second use, when Item_field is already fixed, we do not invoke
the code that mark the underlying Field as used. This causes problem
when one use is for reading and another is for writing.
The problem does not occur for base table fields, since then we have a
distinct Item_field for each field.
The problem does not occur for non-prepared execution since the preparation
order is then different (joined fields before fields to be updated).

Fix: Re-introduce code in fix_fields() that explicitly marks code
when underlying item is fixed.