COLUMNS/INDEXES AND MASTER DOESN'T

DESCRIPTION:
============
With RBR, consider a master having a table and a slave has
added an additional generated column and an index on the
column to that table. Any DML performed on the table in
master corrupts the index on the generated column in the
slave.

ANALYSIS:
=========
When a DML operation is performed on the master, the slave
receives the read_set and/or write_set of the master's
table columns that were involved in the operation. If the
slave's definition of the table has changed, the Slave
assigns default values to those fields. If the extra fields
in the slave are generated columns (virtual/stored), they
cannot be assigned a default value as they do not have one.

Virtual generated column values are not stored by the
storage engine and are calculated on the fly when a SELECT
is performed on the table. Stored Generated columns, on the
other hand, are stored by the storage engine in the
clustered index. If there is a secondary index defined on a
generated column, the generated expression is evaluated and
the value is stored by the engine in the secondary index.

If the Slave's table definition included an extra column
which is a generated column and there was a index defined
on it, the generated column needs to be evaluated and that
value should be passed to the engine in table->record[0]
(and also table->record[1] for UPDATE). In the current
behavior, the column value was not evaluated and instead
a NULL or 0 was assigned to it depending on whether
the column was NULLable. This value is stored by the engine
in the secondary index tree thus corrupting the table.

FIX:
====
In the slave, the generated columns are now re-evaluated
before sending it to the storage engine.

Note:
=====
This patch also backports `diff_tables.inc` from mysql-8.0.

RB#23360

Change-Id: I0ed5bf719ec857076e3789e5b9d91ea01b380bbc