Proposal: per-connection credential provider for short-lived MySQL credentials

[olsonjp]

Problem

Managed MySQL services and other credential providers supply short-lived database credentials: e.g. AWS IAM for RDS, GCP Cloud SQL IAM, and HashiCorp Vault's database secrets engine.  Currently, gh-ost captures a password once and reuses it for the life of the migration, so there is no way to supply a renewed valid credential when a new connection is dialed mid-migration.

New connections are opened in at least the following cases:

• database/sql re-dials after ErrBadConn or a server-side wait_timeout 
• a failover forces reconnection
• the cut-over takes a fresh pinned connection for its lock
• the binlog reader is rebuilt after a streaming failure surfaces

Proposed API and scope

// go/mysql
type PasswordProvider func(ctx context.Context, key InstanceKey) (string, error)

ConnectionConfig.PasswordProvider takes precedence over  Password.MigrationContext. CliPasswordProvider is copied into the connection config by ApplyCredentials. The provider is called immediately before each connection attempt.

This is deliberately an API for programs embedding  gh-ost . It does not add built-in cloud IAM support or a credential-fetching CLI flag, and introduces no cloud SDK dependency. An embedding caller implements it with an AWS SigV4 token, an Entra or Cloud SQL access token, a Vault lease, a password command, or a closure over a static string.

Example: embedding with AWS RDS IAM

ctx.CliPasswordProvider = func(c context.Context, key mysql.InstanceKey)
  (string, error) {
        return auth.BuildAuthToken(
                c, key.DisplayString(), awsConfig.Region, ctx.CliUser, awsConfig.Credentials,
        )
    }
ctx.CliAllowCleartextPasswords = true
ctx.UseTLS = true
ctx.TLSCACertificate = "/etc/ssl/certs/rds-ca-bundle.pem"

Would a library hook be an acceptable first interface, or would you prefer a CLI-facing mechanism such as a credentials file or a password command?