When using field_conv(), which is called in case of field1=field2 copy in
fill_records(), full varstring's was copied, including unitialized bytes.
This caused valgrind to compilain about usage of unitialized bytes when
using Aria static length records.
Fixed by not using memcpy when copying varstrings but instead just copy
the real bytes.

This reverts commit e86010f9.

Reverting on Monty's request, as this change makes merging
things from 10.5 to 10.2 much harder.

Adjust the test for full_crc32.

Problem:
========
Checksum for the encrypted temporary tablespace is not stored in the page
for full crc32 format.

Solution:
========
Made temporary tablespace in full crc32 format irrespective of encryption
parameter.

buf_tmp_page_encrypt(), buf_tmp_page_decrypt() - Both follows full_crc32
format.

This was broken in 2dbe472e

This was broken in the merge 624dd71b

Fixed the following issues:
- Call info with HA_STATUS_CONST to ensure that (key_info->rec_per_key)
  contains latest data
- Don't access rec_per_key if key_info->algorithm == HA_KEY_ALG_LONG_HASH
  is in this case the rec_per_key points to uninitialized data
- Cleaned up code to avoid some extra 'if' and to make things more readable
- Updated test cases that used 'old' rec_per_key values

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.

- Include the valgrind suppressions from the FB upstream

- Use HAVE_Valgrind, not HAVE_Purify (like the rest of MariaDB code does)
  The call to DisownData() is now actually disabled under Valgrind

Using val_decimal_from_int() instead, which provides exactly
the same functionality.

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