Context

Users may want a simple driver solution that does not require a client restart when they rotate TLS certs (e.g. PR #2383). Inline, this behavior can be accomplished using the crypto/tls package's tls#Config.GetClientCertificate closure. In this case, assuming that a user rotates the certificate files but does not signal / restart the driver client, you have that:

• Existing connections: keep working, their handshake is in the past and the new certificates don't affect them.
• New connections: GetClientCertificate reads the file, the new identity is presented, and the handshake succeeds.

Definition of done

• Add an opt-in URI option tlsCertificateRotation=true|false (default false) and a matching SetTLSCertificateRotation(bool) setter. When enabled, the URI-built
• tls.Config sets the GetClientCertificate and VerifyPeerCertificate closures that capture the file paths and read fresh from disk on every new TLS handshake. This can only be allowed if cfg.ClientSessionCache = nil so we need a guard for when a user tries to apply a custom tls.Config with that value set on top of this behavior.

Pitfalls

1. A handshake that lands mid-write (truncate-then-write) will see partial content and fail
2. ApplyURI reads the cert subject at parse time to populate opts.Auth.Username when MONGODB-X509 auth is configured with no explicit username. That eager read must stay. If a user rotates to a cert with a different subject, the username stays pinned to the old subject and X509 auth silently breaks. Should reject authMechanism=MONGODB-X50} + {{lsCertificateRotation=true when the username would be derived from the cert, or document that the cert subject must be table across rotations.