Also fixes:
MDEV-21487: Implement option for mysql_upgrade that allows root@localhost to be replaced
MDEV-21486: Implement option for mysql_install_db that allows root@localhost to be replaced

Add user mariadb.sys to be definer of user view
(and has right on underlying table global_priv for
required operation over global_priv
(SELECT,UPDATE,DELETE))

Also changed definer of gis functions in case of creation,
but they work with any definer so upgrade script do not try
to push this change.

Quotes added to output.

Closes #1044

Implement User_table_json.
Fix scripts to use mysql.global_priv.
Fix tests.

Sort acl_users inside the mysql_rename_user()'s loop, after every
successful iteration.

This is needed because on the next loop's iteration find_user_exact()
is used, which requires correct sorting by name.

Don't distinguish between a "password hash" and "authentication string"
anymore. Now both are stored in mysql.user.authentication_string, both
are handled identically internally. A "password hash" is just how some
particular plugins interpret authentication string.

Set mysql.user.plugin even if there is no password. The server will use
mysql_native_password plugin in these cases, let's make it expicit.

Remove LEX_USER::pwhash.

Truncate_versioning_priv->Delete_history_priv

because the command and the privilege were renamed

because the statement is TRUNCATE, not DELETE

- Changed warning to "'%-.192s.%-.192s' is not of type '%s'" to make the
  english a bit more correct

"Unknown table" to "Unknown view"

MDEV-5999 MySQL Bug#12766319 - 61865: RENAME USER DOES NOT WORK CORRECTLY - REQUIRES FLUSH PRIVILEGES

use update_hostname() to update the hostname.
test case comes from

  commit 0abdeed1d6d
  Author: gopal.shankar@oracle.com <>
  Date:   Thu Mar 29 00:20:54 2012 +0530

    Bug#12766319 - 61865: RENAME USER DOES NOT WORK CORRECTLY -
                          REQUIRES FLUSH PRIVILEGES

FUNCTIONS/PRIVILEGES DIFFERENTLY'.

The problem was that attempt to grant EXECUTE or ALTER
ROUTINE privilege on stored procedure which didn't exist
succeed instead of returning an appropriate error like
it happens in similar situation for stored functions or
tables.

The code which handles granting of privileges on individual
routine calls sp_exist_routines() function to check if routine
exists and assumes that the 3rd parameter of the latter
specifies whether it should check for existence of stored
procedure or function. In practice, this parameter had
completely different meaning and, as result, this check was
not done properly for stored procedures.

This fix addresses this problem by bringing sp_exist_routines()
signature and code in line with expectation of its caller.

by introducing new Item::precedence() method and using it
to decide whether parentheses are required

otherwise we'd need to store sql_mode *per vcol*
(consider CREATE INDEX...) and how SHOW CREATE TABLE would
support that?

Additionally, get rid of vcol::expr_str, just to make sure
the string is always generated and never leaked in the
original form.

- Adding SHOW CREATE TABLE into all DEFAULT tests,
  to cover need_parentheses_in_default() for all items
- Fixing a few items not to print parentheses in DEFAULT:
  spatial function-alike predicates, IS_IPV4 and IS_IPV6 functions,
  COLUMN_CHECK() and COLUMN_EXISTS().

Functions DATABASE() and USER().

MDEV-6066: Merge new defaults from 5.6 and 5.7 (defaults changed, QC can be stopped with no-zero size)

FUNCTIONS/PRIVILEGES DIFFERENTLY'

Fix for bug#11759114 - '51401: GRANT TREATS NONEXISTENT
FUNCTIONS/PRIVILEGES DIFFERENTLY'.

The problem was that attempt to grant EXECUTE or ALTER
ROUTINE privilege on stored procedure which didn't exist
succeed instead of returning an appropriate error like
it happens in similar situation for stored functions or
tables.

The code which handles granting of privileges on individual
routine calls sp_exist_routines() function to check if routine
exists and assumes that the 3rd parameter of the latter
specifies whether it should check for existence of stored
procedure or function. In practice, this parameter had
completely different meaning and, as result, this check was
not done properly for stored procedures.

This fix addresses this problem by bringing sp_exist_routines()
signature and code in line with expectation of its caller.
Conflicts:
	mysql-test/r/grant.result
	mysql-test/t/grant.test
	sql/sp.cc

Added MAX_STATEMENT_TIME user variable to automaticly kill queries after a given time limit has expired.

- Added timer functions based on pthread_cond_timedwait
- Added kill_handlerton() to signal storage engines about kill/timeout
- Added support for GRANT ... MAX_STATEMENT_TIME=#
- Copy max_statement_time to current user, if stored in mysql.user
- Added status variable max_statement_time_exceeded
- Added KILL_TIMEOUT
- Removed digest hash from performance schema tests as they change all the time.
- Updated test results that changed because of the new user variables or new fields in mysql.user

This functionallity is inspired by work done by Davi Arnaut at twitter.
Test case is copied from Davi's work.

Documentation can be found at
https://kb.askmonty.org/en/how-to-limittimeout-queries/

mysql-test/r/mysqld--help.result:
  Updated for new help message
mysql-test/suite/perfschema/r/all_instances.result:
  Added new mutex
mysql-test/suite/sys_vars/r/max_statement_time_basic.result:
  Added testing of max_statement_time
mysql-test/suite/sys_vars/t/max_statement_time_basic.test:
  Added testing of max_statement_time
mysql-test/t/max_statement_time.test:
  Added testing of max_statement_time
mysys/CMakeLists.txt:
  Added thr_timer
mysys/my_init.c:
mysys/mysys_priv.h:
  Added new mutex and condition variables
  Added new mutex and condition variables
mysys/thr_timer.c:
  Added timer functions based on pthread_cond_timedwait()
  This can be compiled with HAVE_TIMER_CREATE to benchmark agains timer_create()/timer_settime()
sql/lex.h:
  Added MAX_STATEMENT_TIME
sql/log_event.cc:
  Safety fix (timeout should be threated as an interrupted query)
sql/mysqld.cc:
  Added support for timers
  Added status variable max_statement_time_exceeded
sql/share/errmsg-utf8.txt:
  Added ER_QUERY_TIMEOUT
sql/signal_handler.cc:
  Added support for KILL_TIMEOUT
sql/sql_acl.cc:
  Added support for GRANT ... MAX_STATEMENT_TIME=#
  Copy max_statement_time to current user
sql/sql_class.cc:
  Added timer functionality to THD.
  Added thd_kill_timeout()
sql/sql_class.h:
  Added timer functionality to THD.
  Added KILL_TIMEOUT
  Added max_statement_time variable in similar manner as long_query_time was done.
sql/sql_connect.cc:
  Added handling of max_statement_time_exceeded
sql/sql_parse.cc:
  Added starting and stopping timers for queries.
sql/sql_show.cc:
  Added max_statement_time_exceeded for user/connects status in MariaDB 10.0
sql/sql_yacc.yy:
  Added support for GRANT ... MAX_STATEMENT_TIME=# syntax, to be enabled in 10.0
sql/structs.h:
  Added max_statement_time user resource
sql/sys_vars.cc:
  Added max_statement_time variables
mysql-test/suite/roles/create_and_drop_role_invalid_user_table.test
  Removed test as we require all fields in mysql.user table.
scripts/mysql_system_tables.sql
scripts/mysql_system_tables_data.sql
scripts/mysql_system_tables_fix.sql
  Updated mysql.user with new max_statement_time field

MDEV-5998 MySQL Bug#11756966 - 48958: STORED PROCEDURES CAN BE LEVERAGED TO BYPASS DATABASE SECURITY

Merge from mysql-5.6:
revno: 3257
committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
branch nick: mysql-trunk-bug11756966
timestamp: Thu 2011-07-14 09:32:01 +0200
message:
  Bug#11756966 - 48958: STORED PROCEDURES CAN BE LEVERAGED TO BYPASS
                 DATABASE SECURITY

  The problem was that CREATE PROCEDURE/FUCTION could be used to
  check the existence of databases for which the user had no
  privileges and therefore should not be allowed to see.

  The reason was that existence of a given database was checked
  before privileges. So trying to create a stored routine in
  a non-existent database would give a different error than trying
  to create a stored routine in a restricted database.

  This patch fixes the problem by changing the order of the checks
  for CREATE PROCEDURE/FUNCTION so that privileges are checked first.
  This means that trying to create a stored routine in a
  non-existent database and in a restricted database both will
  give ER_DBACCESS_DENIED_ERROR error.

  Test case added to grant.test.

10.0 part of the task, fix system tables

FLUSH PRIVILEGES no longer returns an error, when it was successful.
LOCK_grant is no longed unlocked/relocked between tables_priv and procs_priv

than an empty host '' is the same as any-host wildcard '%'.

Replace '' with '%' in the parser (for GRANT ... foo@'') and when loading grant tables.

Side effect: one cannot have foo@'' and foo@'%' both at the same time
(but one can have foo@'%' and foo@'%%')

mysql-test/r/acl_roles_show_grants.result:
  one can do SHOW GRANTS for himself
mysql-test/t/acl_roles_set_role-table-column-priv.test:
  correct error message
mysql-test/t/acl_roles_show_grants.test:
  one can SHOW GRANTS for himself
sql/sql_acl.cc:
  bugfixing:
  * don't assign with && - it can shortcut and the second assignment won't be executed
  * correct the test in check_grant_all_columns() - want_access should not be modified
  *
sql/sql_cmd.h.OTHER:
  add new commands at the end
sql/sql_db.cc:
  don't call acl_get() if all privileges are already satisfied
  (crashes when run with --skip-grants, because acl data stuctures aren't initialized)
sql/sql_parse.cc:
  * test for current_user in get_current_user()
  * map explicitly specified user@host to current_user

It's safe to delete from HASH when traversing it *backwards*, but not *forwards*.

and small collateral changes

mysql-test/lib/My/Test.pm:
  somehow with "print" we get truncated writes sometimes
mysql-test/suite/perfschema/r/digest_table_full.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/dml_handler.result:
  host table is not ported over yet
mysql-test/suite/perfschema/r/information_schema.result:
  host table is not ported over yet
mysql-test/suite/perfschema/r/nesting.result:
  this differs, because we don't rewrite general log queries, and multi-statement
  packets are logged as a one entry. this result file is identical to what mysql-5.6.5
  produces with the --log-raw option.
mysql-test/suite/perfschema/r/relaylog.result:
  MariaDB modifies the binlog index file directly, while MySQL 5.6 has a feature "crash-safe binlog index" and modifies a special "crash-safe" shadow copy of the index file and then moves it over. That's why this test shows "NONE" index file writes in MySQL and "MANY" in MariaDB.
mysql-test/suite/perfschema/r/server_init.result:
  MariaDB initializes the "manager" resources from the "manager" thread, and starts this thread only when --flush-time is not 0. MySQL 5.6 initializes "manager" resources unconditionally on server startup.
mysql-test/suite/perfschema/r/stage_mdl_global.result:
  this differs, because MariaDB disables query cache when query_cache_size=0. MySQL does not
  do that, and this causes useless mutex locks and waits.
mysql-test/suite/perfschema/r/statement_digest.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_consumers.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_long_query.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/rpl/r/rpl_mixed_drop_create_temp_table.result:
  will be updated to match 5.6 when alfranio.correia@oracle.com-20110512172919-c1b5kmum4h52g0ni and anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y are merged
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
  will be updated to match 5.6 when anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y is merged

most tests pass.
5.3 merge is next