chore(deps): Update mysql package dependency to latest version.

[rfk]

Because AFAICT it's got some changes to how pools are handled, and we want to eliminate variables while digging into #108.

[vladikoff]

@jrgm and @rfk to check this

[rfk]

Per discussion with @jrgm, we'll push ahead with trying to make this update stick and then try it out to see if it resolves the connection problem in #108. Unfortunately I'm starting to suspect some sort of bug in the mysql package, as the test failure here is due to a timeout when calling connection.destroy(). AFAICT we're calling it properly so it really shouldn't cause any times, I need to dig into it more.

[rfk]

Blocked on upstream bug: mysqljs/mysql#1291

[rfk]

Well, this escalated quickly...

The intended upgrade to latest node-mysql is indeed blocked by an upstream bug, but in order to find and fix that bug, I ended up spending a lot of quality time with the test suite. I'm rolling my testsuite changes into this PR as well, which include:

• Upgrade to latest tap runner, which includes much better debugging information on timeouts and is what ultimately led to me tracking down the bug
• Latest tap also handles promises well by default, so remove our ptaptest wrapper as well as several no-longer-necessary calls to t.end().
• A bunch of our t.plan calls were stating the wrong number of tests, and these started failing in the newer test runner
• When you use t.plan(n), the test runner will start running the next test as soon as your n'th assertion passes, so if you've got cleanup code to run at the end of a test, racy things can happen. Some tests have grown an additional "and all was well" check at the end of them in order to prevent this.

With mysqljs/mysql#1291 applied locally, I get a clean (and significantly nicer-looking) test run. whew

[rfk]

Alrighty, this is finally ready for review!

It turned out quite churny due to the test updates, but they're mostly mechanical e.g. updating t.plan constants, returning promises rather than calling t.end. @philbooth r?

[philbooth]

The comments don't mention the reason for this but presumably it was just some errant rejection that wasn't being picked up by the pre-promisified tests? Is there a case to be made for an explicit assertion somewhere to cover it, or is it sufficient that the promise simply doesn't reject?

[rfk]

This behaviour didn't match the mysql backend, which silently replaces any existing reset token with a new one. When I upgraded the test runner, the tests started failing with this error.duplicate. So AFAICT we already have test coverage for, for some reason the test was just failing to fail with the old version of the runner!

[philbooth]

Looks good to me. 👍