Make SQL proxy authentication easier and safer

Problem description

Right now "smart SQL proxies" like MaxScale and ProxySQL require that either all the user credentials are defined in the proxy or that "MitM-unsafe" authentication plugins are used. The former approach works with a handful of users but in pratice duplicating the credentials is an impossibly large task. The latter "MitM approach" works and can be implemented using the mysql_native_password authentication plugin but mysql_native_password not secure enough by modern standards.

The way that the "MitM approach" works is that the hashes exposed in mysql.user can be used by the SQL proxy to authenticate as the real client to the database. The only requirement is that the proxy is able to authenticate to the database on its own to be able to read mysql.user.

The solution should fulfill the following needs:

1. Should work with any client side authentication plugin
2. The SQL proxy should not need the client's plaintext password to authenticate

Ideally this would all be done in a way that doesn't require changes to the network protocol.

Ideas

MDEV-20299: Skip authentication in COM_CHANGE_USER if user has "sudo" privilege

The feature described in MDEV-20299 would allow the proxy to authenticate first using its own configured credentials and then send a COM_CHANGE_USER with only the username to the database. If the user configured for the proxy has the required grants, the COM_CHANGE_USER would work even if the COM_CHANGE_USER would normally fail.

SQL command: CHANGE USER

Expose functionality that's similar to the COM_CHANGE_USER protocol command as an SQL command. This makes it possible to masquerade as another user if the original user has the required grants.

This would require:

• New CHANGE USER command.
• New grants for allowing this user masquerading.

Store proxied username in connection attributes

Reserve a value from the connection attributes (e.g. _proxy_user) and use that username for authorization. The authentication should still be done using the username from the HandshakeReponsePacket.. Similarly to the CHANGE USER SQL command, this probably requires a new grant or at least the IP should match the one in proxy_protocol_networks.

The good side of this approach is that it requires no new user-visible commands and no changes to the network protocol. The downside of this is that it technically may cause conflicts in existing applications but as values prefixed with an underscore are already reserved, this should not be a big problem.