driver.ErrBadConn when init packet read fails

[rdallman]

when initializing a connection, we can return drivers.ErrBadConn so that the
sql package can use this information to retry getting a connection. the sql
package will not give us this behavior unless we return that specific error.
pursuant to #302, this operation is another in the limited set of things that
seems safe to retry. we are trying to move to the post-302 world and ran into
this :)

I've run into this when using the new drivers.Conn() interface specifically,
though after digging into the sql package this seems like a similar path for
any query. After changing this return, I end up eventually getting a new conn
that is valid. It appears in my repro like the db was not yet ready, and would
just end up returning an invalid conn and giving up, the InvalidConn err came
from

mysql/packets.go

Line 38 in 4a0c3d7

return nil, ErrInvalidConn

which was the first read on the packet (an EOF). At least, returning a
drivers.ErrBadConn to let the db retry initializing the connection seems like
a safe operation.

thanks for maintaining this library :)

Description

Please explain the changes you made here.

Checklist

• Code compiles correctly
• Created tests which fail without the change (if possible)
• All tests passing
• Extended the README / documentation, if necessary
• Added myself / the copyright holder to the AUTHORS file

[rdallman]

Created tests which fail without the change (if possible)

I have a 100% repro here: mattes/migrate#299 -- where before applying this (#736), running go test fails for the migrate library. that repro relies on the test suite behavior of starting up a mysql instance and waiting for it to be ready. the test suite in this repo appears to rely on a mysql instance already being available before running the tests. I'm happy to discuss options here, but it seems a pretty large divergence in testing methodology and I didn't want to get too far ahead without discussion [if necessary]. thanks again!

[rdallman]

thank you!