Use TABLE::init_one_table(), don't duplicate it.
Put additional initializations into TABLE::init_one_table_for_prelocking()

instead of returning strings for CASCADE/RESTRICT
from every storage engine, use enum values

* wrong results for 5.7 and 10.1- vcols, and for indexed vcols
* only helps in rare cases and only minimally

partitioning was setting subj as a partitioning-specific
hack (GET_FIXED_FIELDS_FLAG field flag to detect partitioning fields)
inside init_lex_with_single_table(). But vcols also use
init_lex_with_single_table(), they run fix_fields()
in open_table_from_share() before partitioning and this messes up
partitioning GET_FIXED_FIELDS_FLAG logic.

When updating a table with virtual BLOB columns, the following might happen:
- an old record is read from the table, it has no virtual blob values
- update_virtual_fields() is run, vcol blob gets its value into the
  record. But only a pointer to the value is in the table->record[0],
  the value is in Field_blob::value String (but it doesn't have to be!
  it can be in the record, if the column is just a copy of another
  columns: ... b VARCHAR, c BLOB AS (b) ...)
- store_record(table,record[1]), old record now is in record[1]
- fill_record() prepares new values in record[0], vcol blob is updated,
  new value replaces the old one in the Field_blob::value
- now both record[1] and record[0] have a pointer that points to the
  *new* vcol blob value. Or record[1] has a pointer to nowhere if
  Field_blob::value had to realloc.

To resolve this we unlink vcol blobs from the pointer to the
data (in the record[1]). Because the value is not *always* in
the Field_blob::value String, we need to remember what blobs
were unlinked. The orphan memory must be freed manually.

To complicate the matter, ha_update_row() is also used in
multi-update, in REPLACE, in INSERT ... ON DUPLICATE KEY UPDATE,
also on REPLACE ... SELECT, REPLACE DELAYED, and LOAD DATA REPLACE, etc

multi-update was setting up read_set/vcol_set in
multi_update::initialize_tables() that is invoked after
the optimizer (JOIN::optimize_inner()). But some rows - if they're from
const tables - will be read already in the optimizer, and these rows
will not have all necessary column/vcol values.

* multi_update::initialize_tables() uses results from the optimizer
  and cannot be moved to be called earlier.
* multi_update::prepare() is called before the optimizer, but
  it cannot set up read_set/vcol_set, because the optimizer
  might reset them (see SELECT_LEX::update_used_tables()).

As a fix I've added a new method, select_result::prepare_to_read_rows(),
it's called from inside the optimizer just before make_join_statistics().

This fixes a bug where handler::read_range_first (for example)
needed to compare vcol values that were not calculated yet.

As a bonus it fixes few cases where vcols were calculated twice

sql_insert.cc calls handler->ha_update_row() for
REPLACE and INSERT... ON DUPLICATE KEY UPDATE

cannot use TABLE:merge_keys for that, because Field::part_of_key
was designed to mark fields for KEY_READ, so a field is not a
"part of key", if only prefix of the field is.

* don't issue an error for ER_KEY_BASED_ON_GENERATED_VIRTUAL_COLUMN
* support keyread on vcols
* callback into the server to compute vcol values from mi_check/mi_repair
* DMLs just work. Automatically.

update tests and results, fix bugs

will be used later by storage engines (e.g. in MyISAM repair or in
InnoDB purge)

because it's only doing to show the table structure, not look
at the data.

always set them according to the repair method used

and declare few other Field getters to be 'const'

Make update_virtual_fields() a method of TABLE, to be consistent
with TABLE::update_default_fields().

TABLE::mark_virtual_col() was polluting table->vcol_set
and that confused the following mark_virtual_col()

make it to work when read_set == vcol_set, that is, when
the caller wants to get a one complete bitmap of all fields
a particular vcol depends on.

it was done only in some access methods, not in all,
so the caller had to update_virtual_fields anyway.

In spatial indexes there can be only one keyseg.
Make it explicit in the code, don't pretend that this can work
with the arbitrary number of keysegs.

and FIELDFLAG_xxx constants

prefer x->field over table->field[x->field->field_index]

only use my_print_error when the error message is not
ER(error_code)

the stage is changed from 'old_stage' to 'new_stage',
not the other way around