pt-kill --log-dsn may not work on Perl 5.8

I can't reproduce this. From the debug here and my own, the correct DSN are being used. The access denied here doesn't seem to be because the wrong DSN info was or wasn't used; the MySQL privs are probably wrong.

Also, --log-dsn from a --config file works for me, but there was an odd line the code. It worked, but it shouldn't, so we were getting lucky that DBI was accepting the odd input as valid. Perhaps this was not the case on the customer's system, i.e. their DBI is more strict. I've written a test for this and fixed the odd line.

I changed the title because the original bug did not exist, it turned out to be a feature limitation. --host default is "localhost", so when a DSN does not specify h, h=localhost is automatically used. There's no easy way around this except this one workaround: put "h=" in a --config file. Yes, nothing after the equals sign. This effectively unsets the --host default and makes it so that hosts have to specified somewhere for each DSN, where "somewhere" means a new --host default, or h in some config file or DSN.

There really was a bug that gave rise to the customer's issue in the first place: the rare Perl scope-closure bug where variables in inner scopes that are kept alive by a closure are lost later when the closure is called. This is fixed by moving the vars to an outer scope. So now all the --log-dsn related vars are in an outer scope.

There was also another problem: the retry code for doing --log-dsn query execution presumed that a reconnect would succeed, so it suppressed the error. So when the customer's reconnect failed, nothing was reported and there was no row in the log table either. Now reconnect errors are reported (though reconnection should cause an error in most cases).

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PT-364