Anomaly of account replication from MySQL instance

[VWagen1989]

Hi, I've encountered a replication issue about the account replicated from a MySQL primary instance. Here's how I produced this issue:

• First, I built a replication stream from the primary MySQL instance(MySQL 8.0.33) to the replica(built based on go-mysql-server).

# Executed on Primary
mysql> CREATE USER 'lol'@'%' IDENTIFIED WITH 'mysql_native_password' BY 'lol';
Query OK, 0 rows affected (0.01 sec)

• Then I create an account on the primary MySQL instance.

# Executed on replica
mysql> select Host, User, plugin, authentication_string, identity from mysql.user where User = 'lol';
+------+------+-----------------------+-----------------------+-------------------------------------------+
| Host | User | plugin                | authentication_string | identity                                  |
+------+------+-----------------------+-----------------------+-------------------------------------------+
| %    | lol  | mysql_native_password |                       | *91D9861DFC07DD967611B8C96953474EF270AD5E |
+------+------+-----------------------+-----------------------+-------------------------------------------+
1 row in set (0.01 sec)

• After that, I found the account was replicated successfully. But I failed connect the replica with the expected user and password, while the same operation on MySQL primary worked as expected.

# Connected to Primary, which succeeded
% mysql -h127.0.0.1 -P33306 -ulol -plol -e "select 1" 
mysql: [Warning] Using a password on the command line interface can be insecure.
+---+
| 1 |
+---+
| 1 |
+---+

# Connected to replica, which failed
% mysql -h127.0.0.1 -P23306 -ulol -plol -e "select 1"                                                                                                                                                                                        
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'lol'

# However, as I connected to replica without password, it succeeded
% mysql -h127.0.0.1 -P23306 -ulol -e "select 1"                                                                                                                                                                                              
+---+
| 1 |
+---+
| 1 |
+---+

As I dived into the implementation of the account replication. I found the root cause is:

• The DDL statement of the 'CREATE USER' sent by primary MySQL instance is "CREATE USER ... IDENTIFIED ... AS '*91D9861DFC07DD967611B8C96953474EF270AD5E'". And then the query string was parsed by dolt-vitess to a "CreateUser" which with empty "Password" and non empty "Identity".
  
• After that, go-mysql-server will persist the authentication data of this user with an empty "Password" string. So I could only connect to the replica without password.

After reading the documentation of "CREATE USER" MySQL. The keyword AS indicates that the following string is a hashed password string for the auth plugin. So I think go-mysql-server should store the hashed password string to the 'authentication_string', not just 'identity' in the table mysql.user.

[VWagen1989]

I've also created a PR #2741. Please take a look :)