Detection of first execution of PS fixed.
More debug info.

For the query having an IN subquery with no tables, we were converting the subquery with an expression between
the left part and the select list of the subquery . This can give incorrect results when we have a condition
in the subquery with a dual table (as this is treated as a no table).

The fix is that we don't do this conversion when we have conds in the subquery with a dual table.

mem_heap_create_block(): Poison the payload area until
mem_heap_alloc() unpoisons it.

Learn both valgrind and asan to catch this bug:

  mem_heap_t* heap = mem_heap_create(1024);
  byte* p = reinterpret_cast<byte*>(heap) + sizeof(mem_heap_t);
  *p = 123;

Overflows of the last allocation in a block will be catched too.

mem_heap_create_block(): poison newly allocated memory

Backport from 10.2

The issue is that we are creating a materialised table with key of length 0 which is incorrect, we should
disable materialisation for such a case.

use the correct handlerton when looking for TRANSACTIONAL=1 support

MDEV-13748 Assertion `status_var.local_memory_used == 0 || !debug_assert_on_not_freed_memory' failed in virtual THD::~THD after query with INTERSECT

my_safe_alloca()/my_safe_afree() work as alloca() or malloc()/free()
depending on the memory size to allocate, that is, depending on
reclength here. They only work correctly if reclength doesn't
change in the middle.

proper fix replacing the hack from b80fa400

don't confuse length of the data area (reclength) with the
offset to the "deleted" mark.

Whenever one copies an IO_CACHE struct, one must remember to call
setup_io_cache, if not, the IO_CACHE's current_pos and end_pos
self-references will point to the previous struct's memory, which
could go out of scope. Commit 90038693
fixes this problem in a more general fashion by removing the
self-references altogether, but for 5.5 we'll keep the old behaviour.

MDEV-15014 Assertion `m_cache_lock_status == LOCKED_NO_WAIT || m_cache_status == DISABLE_REQUEST' failed in Query_cache::free_cache on startup

The assert guards against not-locked or not-requested query cache
disabling. If during startup we disable query cache, we failed to
request disabling.

To disable debug instrumentation, save and restore the original value
of the variable DEBUG_DBUG. Assigning -d,... will enable the output of
a lot of unrelated DBUG messages to the server error log.

First roll back changes, then free Items which can lead to memory freeing.

also cover USE and other built-in commands

mem_heap_free_heap_top(): Remove UNIV_MEM_ASSERT_W() and unpoison
the memory region first, because part of it may have been poisoned
by an earlier mem_heap_free_top() call.
Poison the address range at the end.

mem_heap_block_free(): Poison the address range at the end.

UNIV_MEM_ASSERT_AND_ALLOC(): Replace with UNIV_MEM_ALLOC().
We want to keep the address ranges poisoned (unaccessible) as
long as possible.

UNIV_MEM_ASSERT_AND_FREE(): Replace with UNIV_MEM_FREE().

MDEV-14957: JOIN::prepare gets unusable "conds" as argument

Do not touch merged derived (it is irreversible)

Fix first argument of in_optimizer for calls possible before fix_fields()

Problem:-
 If we create table using myisam/aria then this crashes the server.
  CREATE TABLE t1(a bit(1), b int auto_increment , index(a,b));
  insert into t1 values(1,1);
 Or this query
  CREATE TABLE t1 (b BIT(1), pk INTEGER AUTO_INCREMENT PRIMARY KEY);
  ALTER TABLE t1 ADD INDEX(b,pk);
  INSERT INTO t1 VALUES (1,b'1');
  ALTER TABLE t1 DROP PRIMARY KEY;

Reason:-
 The reason for this is
 1st- find_ref_key() finds what key an auto_increment field belongs to by
  comparing key_part->offset and field->ptr. But BIT fields might have
  zero length in the record, so a key might have many key parts with the
  same offset. That is, comparing offsets cannot uniquely identify the
  correct key part.
 2nd- Since next_number_key_offset is zero it myisam/aria will think that
  auto_increment is in first part of key.
 3nd- myisam/aria will call retrieve_auto_key which will see first key_part
  field as a bit field and call assert(0)

Solution:-
  Many key parts might have the same offset, but BIT fields do not
  support auto_increment. So, we can skip all key parts over BIT fields,
  and then comparing offsets will be unambiguous.

/home/kevg/work/mariadb/sql/sql_partition.cc:286:47: error: cannot initialize a parameter of type 'HA_CREATE_INFO *' (aka 'st_ha_create_information *') with an rvalue of type 'ulonglong' (aka 'unsigned long long')
                                              (ulonglong)0, (uint)0);
                                              ^~~~~~~~~~~~
/home/kevg/work/mariadb/sql/partition_info.h:281:72: note: passing argument to parameter 'info' here
  bool set_up_defaults_for_partitioning(handler *file, HA_CREATE_INFO *info,
                                                                       ^

We don't check for DLSYM in CMake, check for DLOPEN instead.

translate clang __has_feature to gcc macros

The assertion failure was caused by an incorrectly set read_set for
functions in the ORDER BY clause in part of a union, when we are using
a mergeable view and the order by clause can be skipped (removed).

An order by clause can be skipped if it's part of one part of the UNION as
the result set is not meaningful when multiple SELECT queries are UNIONed. The
server is aware of this optimization and tries to remove the order by
clause before JOIN::prepare. The problem is that we need to throw an
error when the ORDER BY clause contains invalid columns. To do this, we
attempt resolving the ORDER BY expressions, then subsequently drop them
if resolution succeeded. However, ORDER BY resolution had the side
effect of adding the expressions to the all_fields list, which is used
to construct temporary tables to store the result. We may be ignoring
the ORDER BY statement, but the tmp table still tried to compute the
values for the expressions, even if the columns are never used.

The assertion only shows itself if the order by clause contains members
which were not previously in the select list, and are part of a
function.

There is an additional question as to why this only manifests when using
VIEWS and not when using a regular table. The difference lies with the
"reset" of the read_set for the temporary table during
SELECT_LEX::update_used_tables() in JOIN::optimize(). The changes
introduced in fdf789a7 cleared the
read_set when a mergeable view is encountered in the TABLE_LIST
defintion.

Upon initial order_list resolution, the table's read_set is updated
correctly. JOIN::optimize() will only reset the read_set if it
encounters a VIEW. Since we no longer have ORDER BY clause in
JOIN::optimize() we never get to correctly update the read_set again.

Other relevant commit by Timour, which first introduced the order
resolution when we "can_skip_sort_order":
883af99e

Solution:
Don't add the resolved ORDER BY elements to all_fields. We only resolve
them to check if an error should be returned for the query. Ignore them
completely otherwise.

It has its limitations, e.g. it assumes that there's only one
gdb and only one valgrind process is running. And a hard-coded
one-second delay might be too short for slow machines.

Still, it's better than "doesn't work at all"

instrument table->record[0], table->record[1] and share->default_values.

One should not access record image beyond share->reclength, even
if table->record[0] has some unused space after it (functions that
work with records, might get a copy of the record as an argument,
and that copy - not being record[0] - might not have this buffer space
at the end). See b80fa400 and 444587d8

more complete TRASH-ing of memroots