Rename deactivate_ddl_log_entry to ddl_log_increment_phase

Part of prepration for: MDEV-17567 Atomic DDL

No notable code changes except moving code around

This change removed 68 explict strlen() calls from the code.

The following renames was done to ensure we don't use the old names
when merging code from earlier releases, as using the new variables
for print function could result in crashes:
- charset->csname renamed to charset->cs_name
- charset->name renamed to charset->coll_name

Almost everything where mechanical changes except:
- Changed to use the new Protocol::store(LEX_CSTRING..) when possible
- Changed to use field->store(LEX_CSTRING*, CHARSET_INFO*) when possible
- Changed to use String->append(LEX_CSTRING&) when possible

Other things:
- There where compiler issues with ensuring that all character set names
  points to the same string: gcc doesn't allow one to use integer constants
  when defining global structures (constant char * pointers works fine).
  To get around this, I declared defines for each character set name
  length.

Before memory leaks was only reported if server stopped normally.
This made it harder to find out where the leaks happened when
debugging test cases.

- Remove 'dummy_for_valgrind' overrun marker as this doesn't help much.
  The element also distorts the sizes of objects a bit, which makes it
  harder to calculate gain in object sizes when doing size optimizations.
- Replace usage of thd_get_current_thd() with _current_thd()
- Avoid one extra call indirection when using thd_get_current_thd(), which
  is used by Sql_alloc, by replacing it with _current_thd()

This patch changes the main name of 3 byte character set from utf8 to
utf8mb3. New old_mode UTF8_IS_UTF8MB3 is added and set TRUE by default,
so that utf8 would mean utf8mb3. If not set, utf8 would mean utf8mb4.

Part1: Functional changes

Backporting upstream changes.
commit a7e1ef858ee82493dd8ad9a76bc9c22fe3b8c05b
Author: Neha Kumari <neha.n.kumari@oracle.com>
Note:
From the upstream patch only the new option binlog_expire_logs_seconds
specific changes are taken.

* Unlike in the upstream patch 'binlog_expire_logs_seconds' does not
  replace the "old" 'expire_logs_days', to preserve backward-compatibility.

* Datatype of 'expire_logs_days' variable is changed to double.

* Default value of 'binlog_expire_logs_seconds=0' similar to
  'expire_logs_days'.

* The purge_time can be specified in days with the micro-day precision.
  Eg:
  expire_logs_days=1 is the same as expire_logs_days=1.000000 to make
    binlog_expire_logs_seconds=86400.
  binlog_expire_logs_seconds=1 is the same as expire_logs_days=0.000012.

* If binary log is disabled and option 'expire_logs_days' or
  'binlog_expire_logs_seconds' used with purge_time > 0 a warning will be
  issued.

Merge 'replication_connection_configuration' table.

Replaced following column:
  - AUTO_POSITION with USING_GTID
Added new columns for:
  - IGNORE_SERVER_IDS
  - DO_DOMAIN_IDS
  - IGNORE_SERVER_IDS
Removed following columns as they are not part of mariadb replication
connection configuration:
  - NETWORK_INTERFACE
  - TLS_VERSION

@sql/mysqld.cc
  Changed "master-retry-count" default value to 100000.

SI_USER is, however in FreeBSD there are a couple of non-kernel
user signal infomations above SI_KERNEL.

Put a fallback just in case there is nothing available.

This patch makes the following changes around variable wsrep_on:

1) Variable wsrep_on can no longer be updated from a session that has
an active transaction running. The original behavior allowed cases
like this:

     BEGIN;
     INSERT INTO t1 VALUES (1);
     SET SESSION wsrep_on = OFF;
     INSERT INTO t1 VALUES (2);
     COMMIT;

With regular transactions this would result in no replication
events (not even value 1). With streaming replication it would be
unnecessarily complex to achieve the same behavior. In the above
example, it would be possible for value 1 to be already replicated if
it happened to fill a separate fragment, while value 2 wouldn't.

2) Global variable wsrep_on no longer affects current sessions, only
subsequent ones. This is to avoid a similar case to the above, just
using just by using global wsrep_on instead session wsrep_on:

      --connection conn_1
      BEGIN;
      INSERT INTO t1 VALUES(1);

      --connection conn_2
      SET GLOBAL wsrep_on = OFF;

      --connection conn_1
      INSERT INTO t1 VALUES(2);
      COMMIT;

The above example results in the transaction to be replicated, as
global wsrep_on will only affect the session wsrep_on of new
connections.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

NI_MAXSERV is only 32 is a bit limiting on unix paths.

use gai_strerror for errors as strings.

Include extra info in log if those are marked as such.

Systemd has a socket activation feature where a mariadb.socket
definition defines the sockets to listen to, and passes those
file descriptors directly to mariadbd to use when a connection
occurs.

The new functionality is utilized when starting as follows:

  systemctl start mariadb.socket

The mariadb.socket definition only needs to contain the network
information, ListenStream= directives, the mariadb.service
definition is still used for service instigation.

When mariadbd is started in this way, the socket, port, bind-address
backlog are all assumed to be self contained in the mariadb.socket
definition and as such the mariadb settings and command line
arguments of these network settings are ignored.
See man systemd.socket for how to limit this to specific ports.

Extra ports, those specified with extra_port in socket activation
mode, are those with a FileDescriptorName=extra. These need
to be in a separate service name like mariadb-extra.socket and
these require a Service={mariadb.service} directive to map to the
original service. Extra ports need systemd v227 or greater
(not RHEL/Centos7 - v219) when FileDescriptorName= was added,
otherwise the extra ports are treated like ordinary ports.

The number of sockets isn't limited when using systemd socket activation
(except by operating system limits on file descriptors and a minimal
amount of memory used per file descriptor). The systemd sockets passed
can include any ownership or permissions, including those the
mariadbd process wouldn't normally have the permission to create.

This implementation is compatible with mariadb.service definitions.
Those services started with:

  systemctl start mariadb.service

does actually start the mariadb.service and used all the my.cnf
settings of sockets and ports like it previously did.

When we are testing under valgrind, we should be
testing the actual code path used in production code.

This optimization of using shutdown did, in pre-2009,
help purify shutdown quickly. In
b125770a this magicly
equated to valgrind, in 2009.

Reviewer: Monty

Reseting -> Resetting
Unknow -> Unknown
capabilites -> capabilities
choosen -> chosen
direcory -> directory
informations -> information
openned -> opened
refered -> referred
to access -> one to access
missmatch -> mismatch
succesfully -> successfully
dont -> don't

Problem was that listen_sockets where not properly protected.
Fixed by adding LOCK_start_thread around closing socket loop.

Other things:
- Removed not necessary test in close_socket(). With the current code
  'sock' can never be INVALID_SOCKET.

Main reason for this was there was a crash in shutdown of the server
in binlog_encryption.encryption_combo-mix and some other tests because
something in listen_sockets where not initialized. Changing to
Dynamic_array caused things to work.
Other reason for removing std::vector was that it is harder to debug,
and not integrated with DBUG, safemalloc, valgrind or memory
calculation and cause code explosions (extra code generated for each
std::vector type used).

As a special hack global memory_used isn't SHOW_LONG_STATUS
but still relies on calc_sum_of_all_status() being called.

followup for 63f91927

Binding to a hostname now makes MariaDB server to listen on all addresses
that hostname resolves to.

Rebased to 10.6 by Daniel Black

Closes: #1668

wsrep_cluster_address_update() causes LOCK_wsrep_slave_threads
to be locked under LOCK_wsrep_cluster_config, while normally
the order should be the opposite.

Fix: don't protect @@wsrep_cluster_address value with the
LOCK_wsrep_cluster_config, LOCK_global_system_variables is enough.

Only protect wsrep reinitialization with the LOCK_wsrep_cluster_config.
And make it use a local copy of the global @@wsrep_cluster_address.

Also, introduce a helper function that checks whether
wsrep_cluster_address is set and also asserts that it can be safely
read by the caller.

* reuse the loop in THD::abort_current_cond_wait, don't duplicate it
* find_thread_by_id should return whatever it has found, it's the
  caller's task not to kill COM_DAEMON (if the caller's a killer)

and other minor changes

One should not change the program arguments!
This change also reduces warnings from the icc compiler.

Almost all changes are just syntax changes (adding const to
'get_one_option function' declarations).

Other changes:
- Added a few cast of 'argument' from 'const char*' to 'char *'. This
  was mainly in calls to 'external' functions we don't have control of.
- Ensure that all reset of 'password command line argument' are similar.
  (In almost all cases it was just adding a comment and a cast)
- In mysqlbinlog.cc and mysqld.cc there was a few cases that changed
  the command line argument. These places where changed to instead allocate
  the option in a MEM_ROOT to avoid changing the argument. Some of this
  code was changed to ensure that different programs did parsing the
  same way. Added a test case for the changes in mysqlbinlog.cc
- Changed a few variables that took their value from command line options
  from 'char *' to 'const char *'.

Problem is that not all plugins are loaded when wsrep_recover is executed.
Thus, we allow unknown system variables and extra system variables during
wsrep_recover. Any unknown system variables would still be caught when
the server starts up normally after the SST.

It seems that memory is not freed when updated value is NULL or
when wsrep is not initialized before shutdown.

The parameter innodb_idle_flush_pct that was introduced in
MariaDB Server 10.1.2 by MDEV-6932 has no effect ever since
the InnoDB changes from MySQL 5.7.9 were applied in
commit 2e814d47.

Let us declare the parameter as MARIADB_REMOVED_OPTION.
For earlier versions, commit ea9cd97f
declared the parameter deprecated.

enable the encryption (and abort on failure) after printing --help,
not before

We will default to MUTEXTYPE=sys (using OSTrackMutex) for those
ib_mutex_t that have not been replaced yet.

The view INFORMATION_SCHEMA.INNODB_SYS_SEMAPHORE_WAITS is removed.

The parameter innodb_sync_array_size is removed.

FIXME: innodb_fatal_semaphore_wait_threshold will no longer be enforced.
We should enforce it for lock_sys.mutex and dict_sys.mutex somehow!

innodb_sync_debug=ON might still cover ib_mutex_t.

Do not resend metadata, if metadata does not change between prepare and
execute of prepared statement, or between executes.

Currently, metadata of *every* prepared statement will be checksummed,
and change is detected once checksum changes.

This is not from ideal, performance-wise. The code for
better/faster detection of unchanged metadata, is already in place, but
currently disabled due to PS bugs, such as MDEV-23913.

Old SDK is missing #define SECURITY_MAX_SID_STRING_CHARACTERS

Tighten access control - deny FILE_CREATE_PIPE_INSTANCE permission to
everyone except current user (the one that runs mysqld)

MDEV-23894 UBSAN: several call to function show_binlog_vars(THD*, st_mysql_show_var*, char*) through pointer to incorrect function type 'int (*)(THD *, st_mysql_show_var *, void *, system_status_var *, enum_var_type) errors

The setting innodb_lock_schedule_algorithm=VATS that was introduced
in MDEV-11039 (commit 021212b5)
causes conflicting exclusive locks to be incorrectly granted to
two transactions. Specifically, in lock_rec_insert_by_trx_age()
the predicate !lock_rec_has_to_wait_in_queue(in_lock) would hold even
though an active transaction is already holding an exclusive lock.
This was observed between two DELETE of the same clustered index record.
The HASH_DELETE invocation in lock_rec_enqueue_waiting() may be related.

Due to lack of progress in diagnosing the problem, we will remove the
option. The unsafe option was enabled by default between
commit 0c15d1a6 (MariaDB 10.2.3)
and the parent of
commit 1cc1d042 (MariaDB 10.2.17, 10.3.9),
and it was deprecated in
commit 295e2d50 (MariaDB 10.2.34).

When process is aborted WSREP deinitialization and memory cleanup is not properly handled.  Other reported leaks are in Galera library and should be fixed there.

Appoligies, had a dirty branch before pushing:

This reverts commit 053653a2.

This reverts commit 0ff89780.

This reverts commit 85b08597.

This reverts commit f3f45e46.

This reverts commit a470b357.

This reverts commit f8b8d202.

This reverts commit 6b6f066f.

This reverts commit a701e9e6.

This reverts commit c1698386.

Extend the syntax accepted by the grammar to account for the new create user
and alter user syntax.