chore: Simplify server cert validation logic to distinguish legacy from CA validation (#910)

Going forward, both GOOGLE_MANAGED_CAS_CA, CUSTOMER_MANAGED_CAS_CA, and future new kinds
of CA will use standard TLS domain name validation using the server certificate SAN records. The certificate
validation logic for the original GOOGLE_MANAGED_INTERNAL_CA is now the exception.

See implementation in other connectors:

feat: Support Private CA for server certificates. GoogleCloudPlatform/cloud-sql-nodejs-connector#408
feat: Support Customer CAS Private CA for server certificates. GoogleCloudPlatform/cloud-sql-jdbc-socket-factory#2095

Author: hessjcg

internal/cloudsql/instance.go

@@ -241,16 +241,17 @@ func (c ConnectionInfo) TLSConfig() *tls.Config {
 	for _, caCert := range c.ServerCACert {
 		pool.AddCert(caCert)
 	}
-	if c.ServerCAMode == "GOOGLE_MANAGED_CAS_CA" ||
-		c.ServerCAMode == "CUSTOMER_MANAGED_CAS_CA" {
-		// For CAS instances, we can rely on the DNS name to verify the server identity.
+	if c.ServerCAMode != "" && c.ServerCAMode != "GOOGLE_MANAGED_INTERNAL_CA" {
+		// By default, use Standard TLS hostname verification name to
+		// verify the server identity.
 		return &tls.Config{
 			ServerName:   c.DNSName,
 			Certificates: []tls.Certificate{c.ClientCertificate},
 			RootCAs:      pool,
 			MinVersion:   tls.VersionTLS13,
 		}
 	}
+	// For legacy instances use the custom TLS validation
 	return &tls.Config{
 		ServerName:   c.ConnectionName.String(),
 		Certificates: []tls.Certificate{c.ClientCertificate},