Server improperly requires client capability bits to be sent IN PLAINTEXT prior to TLS handshake

As I show in CONC-654, MariaDB clients including Connector/C, send a great deal of identifying information about themselves in plaintext in the initial "login request" packet, even if they subsequently switch to TLS:

This client information leakage has a lot of bad consequences in and of itself (details in CONC-654), but the server is also mishandling this information.

In parse_client_handshake_packet (in sql/sql_acl.cc):

1. The server receives the client's initial UNENCRYPTED/plaintext "login request" packet.
2. The server extracts the client's capability bits from that packet: https://github.com/MariaDB/server/blob/c7fe8e5/sql/sql_acl.cc#L13750-L13764
3. The server modifies its assessment of the client capabilities, based on those capability bits: https://github.com/MariaDB/server/blob/c7fe8e5/sql/sql_acl.cc#L13768
   The server's assessment of the client's capabilities have now been read, and irreversibly set, based on an unencrypted, unauthenticated data source.
4. Only after reading the client's capabilities from the plaintext packet does the connection switch to using TLS: https://github.com/MariaDB/server/blob/c7fe8e5/sql/sql_acl.cc#L13771
5. Then the server re-reads the client's TLS-secured "login request" packet: https://github.com/MariaDB/server/blob/11.2/sql/sql_acl.cc#L13791-L13792
   ... but the client capabilities are not updated when reading the actually-secure version of the packet

As a result of this flaw in the server (3+5), the client-side information leakage in CONC-654 cannot be fixed in a backwards-compatible way with existing servers.

Fortunately, there is a straightforward way to fix the server, and to allow the client to send a completely meaningless initial login packet in (1). However, this will require the introduction of a new extend capability bit to inform the client that it has been fixed.