DBI::connect calls leak passwords on failure

[SineSwiper]

The DBI framework is fairly careful to avoid password leakage in debug traces. However, passwords will leak in stack traces any time there is a failure. Connection failures are quite common and because of the Carp::croak call (with $Carp::Verbose on or Carp::Always), will result in a trace like this:

Carp::croak('DBI connect(\'***DSN_STRING***\',\'***USERNAME***\',...) failed: Can\'t connect to MySQL server on \'hostname\' (110)') called at lib/perl5/x86_64-linux/DBI.pm line 692
DBI::__ANON__(undef, undef) called at lib/perl5/x86_64-linux/DBI.pm line 748
DBI::connect('DBI', '***DSN_STRING***', '***USERNAME***', '***UNREDACTED PASSWORD***', 'HASH(0xd1677e0)') called at ...

Any sort of password leakage like this requires clean up in various log sources and a password change. Various users have attempted creative solutions like #40, but it should really be fixed at the source. An easy solution is to redact it as soon as the password is collected:

sub connect {
    my $class = shift;
    my ($dsn, $user, $pass, $attr, $old_driver) = my @orig_args = @_;
    my $driver;
 
    # Hide password in stack trace
    $_[2] = ****';

The @orig_args and $pass are already captured, so those can be used freely, but the stack trace is changed to not print the password.

This is also likely a problem with connect_cached calls, too.