don't duplicate functionality, use TABLE::find_field_by_name()

also, set cached_field_index_ptr for _rowid field

use name hash, just like find_field_in_table() does

replication tests

Standard compatible behavior for UPDATE: all assignments in SET
are executed "simultaneously", not left-to-right. And `SET a=b,b=a`
will swap the values.

cleanup. use "command -v" instead of "which"
simplify some checks.

For placement new, throw() exception specification was removed by
accident in 8fe04a3d , making  debug
tests, that simulate out-of-memory situations, fail (e.g filesort_debug)

Correctly initialize fake IPs.

innobase_add_instant_try(): If the leftmost leaf page does not contain
other records than the 'default row', only empty the table if there
are no successor pages.

When a table or partition which was not empty during a previous
instant ADD COLUMN became empty later, and now with this subsequent
instant ADD COLUMN we have the opportunity to convert the empty table
or partition to 'non-instant' format.

Similarly, if the table or partition is empty to begin with, that is,
it does not even contain a 'default row' record, we can use the
'non-instant' format.

Until now, InnoDB inefficiently compared the aligned fields
FIL_PAGE_PREV, FIL_PAGE_NEXT to the byte-order-agnostic value FIL_NULL.

Timing problem as sometimes table is marked as encrypted but
sometimes we are not sure and table is just marked missing.

Compiler optimizations were switched off due to
MySQL Bug #19424, #36366, #34297, due to an alleged compiler bug.
No  proper analysis of code generation was done back then, thus proof of
a compiler bug is missing.

Even if there was a compiler bug 13 years ago, it could have been fixed.
Will wait and see if there are any complains or crashes

trx_undo_rec_copy(): Use a debug assertion. In a non-debug build,
with len<0 (which this assertion is really testing for)
we should still typically crash due to running out of memory.

Replace all occurrences of the is_clust() method with is_primary(),
because that is what is actually meant. (Also the change buffer
tree would count as a clustered index.)

Rollback attempted to dereference DB_ROLL_PTR=0, which cannot possibly
be a valid undo log pointer. A safer canonical value would be
roll_ptr_t(1) << ROLL_PTR_INSERT_FLAG_POS
which is what was chosen in MDEV-12288, corresponding to reset_trx_id.

No deterministic test case for the bug was found. The simplest test
cases may be related to MDEV-11415, which suppresses undo logging for
ALGORITHM=COPY operations. In those operations, in the spirit of
MDEV-12288, we should actually have written reset_trx_id instead of
using the transaction identifier of the current transaction
(and a bogus value of DB_ROLL_PTR=0). However, thanks to MySQL Bug#28432
which I had fixed in MySQL 5.6.8 as part of WL#6255, access to the
rebuilt table by earlier-started transactions should actually have been
refused with ER_TABLE_DEF_CHANGED.

reset_trx_id: Move the definition to data0type.cc and the declaration
to data0type.h.

btr_cur_ins_lock_and_undo(): When undo logging is disabled, use the
safe value that corresponds to reset_trx_id.

btr_cur_optimistic_insert(): Validate the DB_TRX_ID,DB_ROLL_PTR before
inserting into a clustered index leaf page.

ins_node_t::sys_buf[]: Replaces row_id_buf and trx_id_buf and some
heap usage.

row_ins_alloc_sys_fields(): Init ins_node_t::sys_buf[] to reset_trx_id.

row_ins_buf(): Only if undo logging is enabled, copy trx->id
to node->sys_buf. Otherwise, rely on the initialization in
row_ins_alloc_sys_fields().

row_purge_reset_trx_id(): Invoke mlog_write_string() with reset_trx_id
directly. (No functional change.)

trx_undo_page_report_modify(): Assert that the DB_ROLL_PTR is not 0.

trx_undo_get_undo_rec_low(): Assert that the roll_ptr is valid before
trying to dereference it.

dict_index_t::is_primary(): Check if the index is the primary key.

PageConverter::adjust_cluster_record(): Fix
MDEV-15249 Crash in MVCC read after IMPORT TABLESPACE
by resetting the system fields to reset_trx_id instead of writing
the current transaction ID (which will be committed at the
end of the IMPORT TABLESPACE) and DB_ROLL_PTR=0.
This can partially be viewed as a follow-up fix of MDEV-12288,
because IMPORT should already then have written
DB_TRX_ID=0 and DB_ROLL_PTR=1<<55 to prevent unnecessary
DB_TRX_ID lookups in subsequent accesses to the table.

fix a couple "initialization skipped by goto" and other new errors.

no matching operator delete found; memory will not be freed if initialization throws an exception

Added a no-op delete() for MEM_ROOT based placement-new()

But set _CRT_NONSTDC_NO_WARNINGS to silence silly warnings about
ANSI C function being non-standard

Remove now deprecated GetVersion()/GetVersionEx(),except single case
where where it is really needed, in feedback plugin. Remove checks for
Windows NT.

Avoid old IPv4-only inet_aton, which generated the warning.

The test was used to result in mismatch due to unaccounted specifics
of the master-slave handshake protocol that sets the Slave_IO_Running
status to true while the semisync master status is set to active a bit later.

The test is refined to expect that.

Fixed that Truncate_versioning_privilege works as any other privilege
during upgrade:

- If the privilege field does not exists, add it to the user and db tables.
  If the user had super_privilege then the user will also get the new
  Truncate_versioning_privilege.

This is done to ensure that if one has GRANT ALL PRIVILEGE before, one
will continue to have it after running mysql_upgrade.

This also fixes a bug where the Truncate_versioning_privilege

dict_tf_is_valid(): Allow no-rollback tables in ROW_FORMAT=REDUNDANT.

MDEV-15091 : Windows, 64bit: reenable and fix warning C4267 (conversion from 'size_t' to 'type', possible loss of data)

Handle string length as size_t, consistently (almost always:))
Change function prototypes to accept size_t, where in the past
ulong or uint were used. change local/member variables to size_t
when appropriate.

This fix excludes rocksdb, spider,spider, sphinx and connect for now.

If setting user variable was used in the specification of a recursive CTE
then Item_func_set_user_var::fix_fields() went into an infinite loop.

                 does not return error

Corrected the code of st_select_lex::find_table_def_in_with_clauses() for
a proper identification of CTE references used in embedded CTEs.

Applying https://github.com/MariaDB/server/pull/594
to bb-10.2-ext

When storing '0001-01-01 10:20:30x', execution went throw the last code
branch in Field_time::store_TIME_with_warning(), around the test
for (ltime->year || ltime->month). This then resulted into wrong results
because:

1. Field_time::store_TIME() does not check YYYYMM against zero.
  It assumes that ltime->days and ltime->hours are already properly set.
  So it mixed days to hours, even when YYYYMM was not zero.

2. Field_time_hires::store_TIME() does not check YYYYMM against zero.
  It assumes that ltime->year, ltime->month, ltime->days and ltime->hours
  are already properly set. So it always mixed days and even months(!) and years(!)
  to hours, using pack_time(). This gave even worse results comparing to #2.

3. Field_timef::store_TIME() did not check the entire YYYYMM for being zero.
  It only checked MM, but did not check YYYY. In case of a zero MM,
  it mixed days to hours, even if YYYY was not zero.
  The wrong code was in TIME_to_longlong_time_packed().

In the new reduction Field_time::store_TIME_with_warning() is responsible
to prepare the YYYYYMMDD part properly in all code branches
(with trailing garbage like 'x' and without trailing garbage).
It was reorganized into a more straightforward style.

Field_time:store_TIME(), Field_time_hires::store_TIME() and
TIME_to_longlong_time_packed() were fixed to do a DBUG_ASSERT
on non-zero ltime->year or ltime->month. The code testing ltime->month
was removed from TIME_to_longlong_time_packed(), as it's now
properly done on the caller level.

Truncation was moved from Field_timef::store_TIME() to
Field_time::store_TIME_with_warning().

So now all thee methods Field_time*::store_TIME() assume a properly
set input value:
- Only zero ltime->year and ltime->month are allowed.
- The value must be already properly truncated according to decimals()
  (this will help to add rounding soon, see MDEV-8894)

A "const" qualifier was added to the argument of Field_time*::store_TIME().

Virtial_tmp_table did not set the "field_index" member for its Fields.
Fixing Virtual_tmp_table::add() to set "field_index" to the Field's ordinal position
inside the table, like a normal TABLE does, for consistency.

Although, this flaw did not seem to cause any bugs, having field_index properly
set is helpful for debugging purposes.

1st. Create_field does not have function vers_sys_field() kind of handy
function, second I think Create_field and Field should not divert much , and
Field does have this function.

2nd. Versioning column does not have NOT_NULL_FLAG, since they can never be
null. So I have added NOT_NULL_FLAG.

3rd. Since I added NOT_NULL_FLAG this created one issue , versioning column
of datatype bigint unsigned were getting NO_DEFAULT_VALUE_FLAG. This makes
test like versioning.insert to fail, Reason being If a column gets this
flag if we insert 'default' value it will generate error(that is why ) test
was failing. So now versioning column wont get NO_DEFAULT_VALUE_FLAG flag.

Problem:-
  create or replace table t1 (pk int auto_increment primary key invisible, i int);
  alter table t1 modify pk int invisible;
 This last alter makes a invisible column which is not null and does not
 have default value.

Analysis:-
 This is caused because our error check for NOT_NULL_FLAG and
 NO_DEFAULT_VALUE_FLAG flag misses this sql_field , but this is not the fault
 of error check :).Actually this field come via mysql_prepare_alter_table
 and it does not have NO_DEFAULT_VALUE_FLAG flag turned on. (If it was create
 table NO_DEFAULT_VALUE_FLAG would have turned on Column_definition::check)
 and this would have generated error.

Solution:-
 I have moved the error check to kind last of mysql_prepare_create_table
 because upto this point we have applied NO_DEFAULT_VALUE_FLAG to required
 column.