The names rows_for_plan and cost_for_plan follow MySQL
Also added post-join-operation selectivity cost

Starting with commit 210855ce
Valgrind became aware that the unused tail of the buffer that
is returned by thd_get_xid() is actually uninitialized.

The problem should exist already in MySQL 5.0. I was able to
repeat it on MariaDB Server 5.5 with some additional instrumentation.
InnoDB is allocating 128+4+4 bytes for the XID and the lengths of
its components, even when the XID is shorter than 64+64 bytes.
In MariaDB Server 10.3, while running the test main.xa_binlog,
in the xid_t::set() that is called by sql_yacc.yy, the 128-byte data
buffer was uninitialized according to Valgrind, and only the first bytes
were initialized. When the xid_t::data was copied to
thd.transaction.xid_state.xid.data, it happened so that the entire
target buffer was considered initialized. With MariaDB Server 10.4 since
the said commit, Valgrind will correctly be detect the tail of the buffer
as uninitialized.

The impact of this bug is as follows:

(1) InnoDB will write unnecessarily much redo log for XA PREPARE.
(2) InnoDB will write garbage bytes to the redo log and undo log pages.
(3) The garbage should be 'harmless', because on recovery, only the
actual payload of the XID will be used, based on the written length.

trx_rseg_write_wsrep_checkpoint(), trx_undo_write_xid(): Write only
the actually used length of xid->data to the data page, and
zero out the rest of the buffer by mlog_memset().

This fixes the following test failures related to index cardinality:
main.join main.stat_tables main.partition main.stat_tables_innodb
innodb.innodb_bug57252

- Initialize variables that could be used uninitialized
- Added extra end space to DbugStringItemTypeValue to get rid of warnings
  from c_ptr()
- Session_sysvars_tracker::update() accessed unitialized memory if called
  with NULL value.
- get_schema_stat_record() accessed unitialized memory if HA_KEY_LONG_HASH
  was used
- parse_vcol_defs() accessed random memory for tables without keys.

Reusing the MIN()/MAX() fix_length_and_dec() related code for window functions
- FIRST_VALUE()
- LAST_VALUE()
- NTH_VALUE()
- LEAD()
- LAG

Part#2: update .result files for affected MyRocks tests

MDEV-19301 Assertion `!is_valid_datetime() || fraction_remainder(((item->decimals) < (6) ? (item->decimals) : (6))) == 0' failed in Datetime_truncation_not_needed::Datetime_truncation_not_needed

- Removing the wrong assert
- Re-enabling  multi_source.mdev-8874

Adding tests only.

This problem was earlier fixed in 10.4 by MDEV-17325 and backported to 10.3
with this commit:

  f4019f5b

Ignore the setreuid() return here.

Make sure that the references in the GROUP BY clause that need to be considered for
pushdown from having to where are of Item_field objects

Use LOCK_server_started, COND_server_started and mysqld_server_started for waiting starting the server

Warning added.

Do not cast wrong type.

We use own IO callbacks from server code anyway.