Unclear requirements on how auth-plugin-data is sent to the client in the initial
server-packet leads to situations where the client can't authenticate to a server.
This patch introduces an incompatible change to fix this.
  
A concrete example when this happens is when Connector/J 5.1.18 and 
server option  --default-authentication-plugin=sha256_password  is used.

Background:
The sha256_password plugin wants to send a 20-bytes salt to the client
which is split into 8 + 12 bytes according to
http://dev.mysql.com/doc/internals/en/connection-phase-packets.html#packet-Protocol::HandshakeV10

The 2nd part (12 bytes) + the auth-plugin-name looks like
    ...KHe8SY[]bP9rsha256_password\0
If default-authentication-plugin would be left at its default value
"mysql_native_password" the same data would look like:
    ...KHe8SY[]bP9r\0mysql_native_password\0
 (note the extra \0 before mysql_native_password)
 If a client connects that doesn't understand the CLIENT_PLUGIN_AUTH
capability (like C/J 5.1.18) they will read up to the terminating \0
and will use the scramble to authenticate.
Other older connectors like libmysql-5.1 always only read 12 bytes and
ignore everything after that. Therefore they are not affected by the
missing \0 character.
One could argue that reading always 12 bytes is the correct way, but
that doesn't match what the 5.1 (and earlier) server send:
  ...KHe8SY[]bP9r\0
If it would be fixed size, there would be no need for the \0.
Whatever the original intent was there are two ways to parse this data:
1) read up to the \0 byte
2) read 12 bytes, ignore the rest

All connectors that take the route of 1) break in the mysql-server
configuration described above.

Bug has the PIG-stamp-of-approval.