MDEV-8743: use CLOEXEC to protect mariadb files from sst script touching

Thread 1 "mysqld" hit Breakpoint 1, innobase_mysql_tmpfile () at /home/dan/repos/mariadb-server-5.5/storage/xtradb/handler/ha_innodb.cc:1639
1639            os_event_wait(srv_allow_writes_event);

(gdb) p fd
$2 = 7
(gdb) n
1682                    fd2 = fcntl(fd, F_DUPFD_CLOEXEC, 0);
(gdb)
1687                    if (fd2 < 0) {
(gdb) p fd2
$3 = 8

cat /proc/20448/fdinfo/{7,8}
  2051972      0 -r--------   1  dan      dan             0 Mar  2 12:04 fdinfo/7
pos:    0
flags:  0100002
mnt_id: 82
  2051973      0 -r--------   1  dan      dan             0 Mar  2 12:04 fdinfo/8
pos:    0
flags:  02100002
mnt_id: 82

So fd 8 has 02000000 hence CLOEXEC

From 0f447810

For galera compatibility, the main thing is to ensure the FD 1, 2 are
not opened with O_CLOEXEC otherwise galera sst errors don't appear in
the error.log

Files without O_CLOEXEC from the test below:
0 -> /dev/pts/9
1 -> /tmp/error.log (intended)
2 -> /tmp/error.log (intended)
5 -> /tmp/datadir
6 -> /tmp/datadir/aria_log.00000001
(Innodb temp files)
8 -> /tmp/ibIIrhFL (deleted)
9 -> /tmp/ibfx1vai (deleted)
10 -> /tmp/ibAQUKFO (deleted)
11 -> /tmp/ibWBQSHR (deleted)
15 -> /tmp/ibEXEcfo (deleted)

20 -> /tmp/datadir/mysql/host.MYD
22 -> /tmp/datadir/mysql/user.MYD
... (rest of MYD files)

Test for this and the previous commit.

 sql/mysqld --skip-networking --datadir=/tmp/datadir --log-bin=/tmp/datadir/mysqlbin --socket /tmp/s.sock --lc-messages-dir=${PWD}/sql/share --verbose --log-error=/tmp/error.log --general-log-file=/tmp/general.log --general-log=1 --slow-query-log-file=/tmp/slow.log --slow-query-log=1
180302 10:56:41 [Note] sql/mysqld (mysqld 5.5.60-MariaDB-wsrep) starting as process 26056 ...

$ cd /proc/26056
$ ls -la --sort=none fd
total 0
dr-x------. 2 dan dan  0 Mar  2 10:57 .
dr-xr-xr-x. 9 dan dan  0 Mar  2 10:56 ..
lrwx------. 1 dan dan 64 Mar  2 10:57 0 -> /dev/pts/9
l-wx------. 1 dan dan 64 Mar  2 10:57 1 -> /tmp/error.log
l-wx------. 1 dan dan 64 Mar  2 10:57 2 -> /tmp/error.log
lrwx------. 1 dan dan 64 Mar  2 10:57 3 -> /tmp/datadir/mysqlbin.index
lrwx------. 1 dan dan 64 Mar  2 10:57 4 -> /tmp/datadir/aria_log_control
lr-x------. 1 dan dan 64 Mar  2 10:57 5 -> /tmp/datadir
lrwx------. 1 dan dan 64 Mar  2 10:57 6 -> /tmp/datadir/aria_log.00000001
lrwx------. 1 dan dan 64 Mar  2 10:57 7 -> /tmp/datadir/ibdata1
lrwx------. 1 dan dan 64 Mar  2 10:57 8 -> /tmp/ibIIrhFL (deleted)
lrwx------. 1 dan dan 64 Mar  2 10:57 9 -> /tmp/ibfx1vai (deleted)
lrwx------. 1 dan dan 64 Mar  2 10:57 10 -> /tmp/ibAQUKFO (deleted)
lrwx------. 1 dan dan 64 Mar  2 10:57 11 -> /tmp/ibWBQSHR (deleted)
lrwx------. 1 dan dan 64 Mar  2 10:57 12 -> /tmp/datadir/ib_logfile0
lrwx------. 1 dan dan 64 Mar  2 10:57 13 -> /tmp/datadir/ib_logfile1
l-wx------. 1 dan dan 64 Mar  2 10:57 14 -> /tmp/slow.log
lrwx------. 1 dan dan 64 Mar  2 10:57 15 -> /tmp/ibEXEcfo (deleted)
l-wx------. 1 dan dan 64 Mar  2 10:57 16 -> /tmp/general.log
lrwx------. 1 dan dan 64 Mar  2 10:57 17 -> socket:[1897356]
lrwx------. 1 dan dan 64 Mar  2 10:57 18 -> socket:[45335]
l-wx------. 1 dan dan 64 Mar  2 10:57 19 -> /tmp/datadir/mysqlbin.000004
lrwx------. 1 dan dan 64 Mar  2 10:57 20 -> /tmp/datadir/mysql/host.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 21 -> /tmp/datadir/mysql/host.MYI
lrwx------. 1 dan dan 64 Mar  2 10:57 22 -> /tmp/datadir/mysql/user.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 23 -> /tmp/datadir/mysql/user.MYI
lrwx------. 1 dan dan 64 Mar  2 10:57 24 -> /tmp/datadir/mysql/db.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 25 -> /tmp/datadir/mysql/db.MYI
lrwx------. 1 dan dan 64 Mar  2 10:57 26 -> /tmp/datadir/mysql/proxies_priv.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 27 -> /tmp/datadir/mysql/proxies_priv.MYI
lrwx------. 1 dan dan 64 Mar  2 10:57 28 -> /tmp/datadir/mysql/tables_priv.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 29 -> /tmp/datadir/mysql/tables_priv.MYI
lrwx------. 1 dan dan 64 Mar  2 10:57 30 -> /tmp/datadir/mysql/columns_priv.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 31 -> /tmp/datadir/mysql/columns_priv.MYI
lrwx------. 1 dan dan 64 Mar  2 10:57 32 -> /tmp/datadir/mysql/procs_priv.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 33 -> /tmp/datadir/mysql/procs_priv.MYI
lrwx------. 1 dan dan 64 Mar  2 10:57 34 -> /tmp/datadir/mysql/servers.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 35 -> /tmp/datadir/mysql/servers.MYI
lrwx------. 1 dan dan 64 Mar  2 10:57 36 -> /tmp/datadir/mysql/event.MYD
lrwx------. 1 dan dan 64 Mar  2 10:57 37 -> /tmp/datadir/mysql/event.MYI

O_CLOEXEC files are those with flags 02000000

/usr/include/bits/fcntl-linux.h:# define __O_CLOEXEC   02000000
/usr/include/bits/fcntl-linux.h:# define O_CLOEXEC      __O_CLOEXEC     /* Set close_on_exec.  */

$ find fdinfo/ -type f -ls -exec cat {} \; | more
  1924720      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/0
pos:    0
flags:  0100002
mnt_id: 25
  1924721      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/1
pos:    9954
flags:  0102001
mnt_id: 82
  1924722      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/2
pos:    10951
flags:  0102001
mnt_id: 82
  1924723      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/3
pos:    116
flags:  02100002
mnt_id: 82
  1924724      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/4
pos:    52
flags:  0100002
mnt_id: 82
lock:   1: POSIX  ADVISORY  WRITE 26056 00:2c:1866365 0 EOF
  1924725      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/5
pos:    0
flags:  0100000
mnt_id: 82
  1924726      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/6
pos:    16384
flags:  0100002
mnt_id: 82
  1924727      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/7
pos:    0
flags:  02100002
mnt_id: 82
lock:   1: POSIX  ADVISORY  WRITE 26056 00:2c:1866491 0 EOF
  1924728      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/8
pos:    0
flags:  0100002
mnt_id: 82
  1924729      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/9
pos:    0
flags:  0100002
mnt_id: 82
  1924730      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/10
pos:    0
flags:  0100002
mnt_id: 82
  1924731      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/11
pos:    0
flags:  0100002
mnt_id: 82
  1924732      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/12
pos:    0
flags:  02100002
mnt_id: 82
lock:   1: POSIX  ADVISORY  WRITE 26056 00:2c:1866492 0 EOF
  1924733      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/13
pos:    0
flags:  02100002
mnt_id: 82
lock:   1: POSIX  ADVISORY  WRITE 26056 00:2c:1866493 0 EOF
  1924734      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/14
pos:    763
flags:  02102001
mnt_id: 82
  1924735      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/15
pos:    0
flags:  0100002
mnt_id: 82
  1924736      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/16
pos:    473
flags:  02102001
mnt_id: 82
  1924737      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/17
pos:    0
flags:  02000002
mnt_id: 9
  1924738      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/18
pos:    0
flags:  02
mnt_id: 9
  1924739      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/19
pos:    245
flags:  02100001
mnt_id: 82
  1924740      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/20
pos:    0
flags:  0100002
mnt_id: 82
  1924741      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/21
pos:    503
flags:  0500002
mnt_id: 82
  1924742      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/22
pos:    324
flags:  0100002
mnt_id: 82
  1924743      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/23
pos:    642
flags:  0500002
mnt_id: 82
  1924744      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/24
pos:    880
flags:  0100002
mnt_id: 82
  1924745      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/25
pos:    581
flags:  0500002
mnt_id: 82
  1924746      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/26
pos:    1386
flags:  0100002
mnt_id: 82
  1924747      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/27
pos:    498
flags:  0500002
mnt_id: 82
  1924748      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/28
pos:    0
flags:  0100002
mnt_id: 82
  1924749      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/29
pos:    513
flags:  0500002
mnt_id: 82
  1924750      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/30
pos:    0
flags:  0100002
mnt_id: 82
  1924751      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/31
pos:    494
flags:  0500002
mnt_id: 82
  1924752      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/32
pos:    0
flags:  0100002
mnt_id: 82
  1924753      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/33
pos:    535
flags:  0500002
mnt_id: 82
  1924754      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/34
pos:    0
flags:  0100002
mnt_id: 82
  1924755      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/35
pos:    396
flags:  0500002
mnt_id: 82
  1924756      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/36
pos:    0
flags:  0100002
mnt_id: 82
  1924757      0 -r--------   1  dan      dan             0 Mar  2 10:57 fdinfo/37
pos:    517
flags:  0500002
mnt_id: 82

MDEV-15046 - "Address already in use" on restart

SST processes should inherit mysqld's process group.

Fix WinUIDialogBmp.jpg to use correct dimensions

Use new grey logo.

MEMORY engine needs the record length to be at least sizeof(void*),
because it stores a pointer there (linking deleted records into a list).
So when the reclength is less than sizeof(void*), it's set to sizeof(void*).
That is done inside heap_create(), and the upper layer doesn't know
that the engine writes beyond share->reclength.

While it's usually safe (in-memory record size is rounded up to
sizeof(double), so even if share->reclength is too small,
share->rec_buff_len is not), it could cause problems in the code that
copies records and expects them to fix in share->reclength,
e.g. in partitioning.

* get_rec_bits() was always reading two bytes, even if the
  bit field contained only of one byte
* In various places the code used field->pack_length() bytes
  starting from field->ptr, while it should be field->pack_length_in_rec()
* Field_bit::key_cmp and Field_bit::cmp_max passed field_length as
  an argument to memcmp(), but field_length is the number of bits!

if the property is not found, set it to the empty string,
otherwise it'll show as libmysql_link_flags-NOTFOUND on the linker
command line, and the linker won't like it.

Also, don't specify LINK_FLAG_NO_UNDEFINED twice, MERGE_LIBRARIES
already put it into LINK_FLAGS.

optimizer_switch

For DATE and DATETIME columns defined as NOT NULL,
"date_notnull IS NULL" has to be modified to:
"date_notnull IS NULL OR date_notnull == 0"
if date_notnull is from an inner table of outer join);
"date_notnull == 0" - otherwise.

This must hold for such columns of mergeable views and derived
tables as well. So far the code did the above re-writing only
for columns of base tables and temporary tables.

1. test readdir_r() availability under -Werror
2. don't protect readdir() with mutexes, it's not needed for the way
   we use readdir()

gcc 6 issues a warning about a suspicious construct

  while(0);
  {
     some code
  }

Enumerate plugins that use password field.

The function trans_rollback_to_savepoint(), unlike trans_savepoint(),
did not allow xa_state=XA_ACTIVE, so an attempt to do ROLLBCK TO SAVEPOINT
inside an XA transaction incorrectly returned an error
"...command cannot be executed ... in the ACTIVE state...".

Partially merging a MySQL patch:
  7fb5c47390311d9b1b5367f97cb8fedd4102dd05
  This is WL#7193 (Decouple THD and st_transactions)...

The currently merged part includes these changes:
- Introducing st_xid_state::check_has_uncommitted_xa()
- Reusing it in both trans_rollback_to_savepoint() and trans_savepoint(),
  so now both allow XA_ACTIVE.

The problem was in such scenario:
T1 - starts registering query and locked QC
T2 - starts disabling QC and wait for UNLOCK
T1 - unlock QC
T2 - disable QC and destroy signals without waiting for query unlock
T1 a) - not yet unlocked query in qc and crash on attempt to unlock because
        QC signals are destroyed
   b) if above was done before destruction, it execute end_of results first
      time at exit on after try_lock which see QC disables and return TRUE.
      But it do not reset query_cache_tls->first_query_block which lead to
      second call of end_of_result when diagnostic arena has already
      inappropriate status (not is_eof()).

Fix is:
  1) wait for all queries unlocked before destroying them by locking and
     unlocking
  2) remove query_cache_tls->first_query_block if QC disabled

Regression after 5ea28015.

with joins, SQ, ORDER BY, semijoin=on

A bug in get_sort_by_table() could mislead the function
setup_semijoin_dups_elimination(). As a result the optimizer
could produce invalid execution plans for queries with ORDER BY
and subquery predicates that could be converted to semi-joins.

Remove non prepared (and so belonging to removed clauses FT functions) from the list.

in later version it will be fixed by building the list during preparation.

Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>

Fix the call to correspond protocoll of pagecache call.
Fix of misleading variables names.