migrate-db: redact credentials from the postgres DSN in logs

[djkazic]

migrate-db logs the destination postgres DSN verbatim, and the DSN is where
the database password lives:

[INF] LNDINIT Opening postgres backend at `postgres://lnd:hunter2@postgres:5432/lnd?sslmode=disable` with prefix `channeldb`

The line is at info level, which is what -v selects since #98; before that PR
-v set the level to error and kept the password out of stderr. In the k8s
setup lndinit is built for, stderr is the pod log.

The line predates #98 and the handler defaults to info, so an invocation with no
flags at all printed the DSN before as well. Fixing the log line covers both
paths, which is why this doesn't touch the -v change.

redactDsn keeps only the parameters known not to hold a secret and drops
everything else, rather than hunting for the ones that do: a blocklist that is
wrong once prints the password, an allow list that is wrong just prints less.
A DSN that doesn't parse is replaced wholesale. Both notations pgx accepts are
handled, since a password can sit in the userinfo section, in a query parameter
or in a password= field:

DSN	logged as
postgres://alice:s3cr3t@localhost:5432/lnd?sslmode=disable	postgres://alice@localhost:5432/lnd?sslmode=disable
postgres://alice@localhost:5432/lnd?password=s3cr3t	postgres://alice@localhost:5432/lnd
host=localhost user=alice password=s3cr3t dbname=lnd	host=localhost user=alice dbname=lnd
postgres://alice:s3cr3t@loc alhost/lnd	[redacted]

Host, port, database and user survive, which is what the line is there for.

TestRedactDsn covers each notation, the three hiding places, an unparsable DSN
and a quoted value with spaces, asserting on every case that the password
appears nowhere in the output. The other logger.Info sites log secret names,
not values, so this was the only one the level change widened.

[Roasbeef]

LGTM