protocol: try to adapt MySQL bug #79612(Connector / J)

## Enhancement

There's a known bug of MySQL Connector / J versions 5.1.25 - 5.1.45, see for more details https://bugs.mysql.com/bug.php?id=79612.

The bug violates connection protocol, which makes MySQL & TiDB fail to parse the connection attributes:

* MySQL 5.7.35: fail to parse the connection attributes, there is no connection attribute for the related connection.
* MySQL 8.0.32: fail to establish the connection with an exception: "`Caused by: java.lang.NullPointerException: Cannot invoke "java.util.Map.get(Object)" because "this.serverVariables" is null`".
* TiDB(all versions): fail to parse the connection attributes([a `WARN` message will be logged](https://github.com/pingcap/tidb/blob/9176d206c9b130a5e56f95543740cad66eb469ca/server/internal/parse/parse.go#L472-L482)), there is no connection attribute for the related connection.

Here we would like to make some discussions in this issue on the possibility of adapting this bug, which looks possible:

When CLIENT_CONNECT_WITH_DB is not set, it shouldn't be skipped originally. However, a `null` value was added to the JDBC connection. This caused the server to misinterpret the offset during parsing, leading to errors in parsing subsequent authentication plugins and connection attributes. One of these attributes, the authentication plugin, is empty, resulting in the server sending a switch auth request and an additional round of password verification.

If following the normal parsing order, it's challenging to determine whether the null value belongs to the authentication plugin or the default database.

The solution is to treat the `null` value as the database when `auth plugin=""`, and then check the following authentication plugin for validity.