* rpm upgrade fix
* update test results
* valgrind warning

        Now JSON functions return warnings if arguments are invalid.

name innodb background threads as such

MDEV-11518 Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed in Field_long::val_int()

QUICK_RANGE_SELECT::init_ror_merged_scan() should
also set and restore TABLE::vcol_set

Aria supports virtual columns, but does not support indexes
on virtual columns. Let's issue an appropriate error in this case.

strangely enough, ?: variant does not link in some older gcc versions:

sql/sql_table.cc:6409: undefined reference to `Alter_inplace_info::ALTER_STORED_GCOL_EXPR'
sql/sql_table.cc:6409: undefined reference to `Alter_inplace_info::ALTER_VIRTUAL_GCOL_EXPR'

by introducing new Item::precedence() method and using it
to decide whether parentheses are required

* do setup/cleanup for charset and arena only once per table
  not for every vcol
* don't copy every vcol expression into table's memroot for parsing,
  do it in a temporary String buffer that is freed at the end
* add asserts

now, when expr_str is gone, expr_item can be unambiguously
renamed to expr.

otherwise we'd need to store sql_mode *per vcol*
(consider CREATE INDEX...) and how SHOW CREATE TABLE would
support that?

Additionally, get rid of vcol::expr_str, just to make sure
the string is always generated and never leaked in the
original form.

it must, because purge opens a table that might be being altered right now

  * remove old 5.2+ InnoDB support for virtual columns
  * enable corresponding parts of the innodb-5.7 sources
  * copy corresponding test cases from 5.7
  * copy detailed Alter_inplace_info::HA_ALTER_FLAGS flags from 5.7
     - and more detailed detection of changes in fill_alter_inplace_info()
  * more "innodb compatibility hooks" in sql_class.cc to
     - create/destroy/reset a THD (used by background purge threads)
     - find a prelocked table by name
     - open a table (from a background purge thread)

  * different from 5.7:
    - new service thread "thd_destructor_proxy" to make sure all THDs are
      destroyed at the correct point in time during the server shutdown
    - proper opening/closing of tables for vcol evaluations in
       + FK checks (use already opened prelocked tables)
       + purge threads (open the table, MDLock it, add it to tdc, close
         when not needed)
    - cache open tables in vc_templ
    - avoid unnecessary allocations, reuse table->record[0] and table->s->default_values
    - not needed in 5.7, because it overcalculates:
      + tell the server to calculate vcols for an on-going inline ADD INDEX
      + calculate vcols for correct error messages

  * update other engines (mroonga/tokudb) accordingly

remove 'table' argument, remnant of 5.6, does not exist in 5.7

* remnant of 5.6, does not exist in 5.7. bad merge?
* also remove dict_table_get_col_name_for_mysql(), it was only
  used when index_field_t::col_name was not NULL

* fix "unused pending_checkpoint_mutex_key" compiler warning
* clarify/simplify get_field_offset()
* typos, comments
* unused (forgotten) declaration of create_options_are_invalid()
* fix my_error(ER_WRONG_KEY_COLUMN) calls
* crash in row_upd_sec_index_entry()
* double if (ret != 0)
* don't duplucate PSI_INSTRUMENT_ME lines
* useless break; after return();
* remove unused xtradb-only "cursor_read_view" stuff
* code formatting
* simplify dropped column detection
* redundant assignment

and THD::inc_thread_count

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