Per b9f3f068, mysql_system_tables_data.sql creates
a mysql_native_password with a salted hash of "invalid" so that `set password`
will detect a native password can be applied:.

SHOW CREATE USER; diligently uses this value in its output
generating the SQL:

   MariaDB [(none)]> show create user;

   +---------------------------------------------------------------------------------------------------+
   | CREATE USER for dan@localhost                                                                     |
   +---------------------------------------------------------------------------------------------------+
   | CREATE USER `dan`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket |
   +---------------------------------------------------------------------------------------------------+

Attempting to execute this before this patch results in:

  MariaDB [(none)]>  CREATE USER `dan2`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket;
  ERROR 1372 (HY000): Password hash should be a 41-digit hexadecimal number

As such, deep the implementation of mysql_native_password we make "invalid" valid (pun intended)
such that the above create user will succeed. We do this by storing
"*THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE" (credit: Oracle MySQL), that is of an INCORRECT
length for a scramble.

In native_password_authenticate we check the length of this cached value
and immediately fail if it is anything other than the scramble length.

native_password_get_salt is only called in the context of set_user_salt, so all setting of native
passwords to hashed content of 'invalid', quite literally create an invalid password.

So other forms of "invalid" are valid SQL in creating invalid passwords:

   MariaDB [(none)]> set password = 'invalid';
   Query OK, 0 rows affected (0.001 sec)

   MariaDB [(none)]> alter user dan@localhost IDENTIFIED BY PASSWORD 'invalid';
   Query OK, 0 rows affected (0.000 sec)

closes #1628

Reviewer: serg@mariadb.com