[SPARK-46608][SQL] Restore backward compatibility of JdbcDialect.classifyException

[MaxGekk]

What changes were proposed in this pull request?

In the PR, I propose to restore classifyException() of JdbcDialect before the commit 14a933b, and extends classifyException() with the error class parameter by description:

  def classifyException(
      e: Throwable,
      errorClass: String,
      messageParameters: Map[String, String],
      description: String): AnalysisException

The description parameter has the same meaning as message in the old version of classifyException() which is deprecated.

Also old implementation of classifyException() has been restored in JDBC dialects: MySQL, PostgreSQL and so on.

Why are the changes needed?

To restore compatibility with existing JDBC dialects.

Does this PR introduce any user-facing change?

No, this PR restores the behaviour prior #44358.

How was this patch tested?

By running the affected test suite:

$ build/sbt "core/testOnly *SparkThrowableSuite"

and modified test suite:

$ build/sbt "test:testOnly *JDBCV2Suite"
$ build/sbt "test:testOnly *JDBCTableCatalogSuite"

Was this patch authored or co-authored using generative AI tooling?

No.

[cloud-fan]

Instead of passing description around, shall we generate the description here using the error class name and the tableName in the parameters?

[MaxGekk]

This might be not fully compatible with existing JDBC dialects because values in messageParameters has been preprocessed already like quoting, and a JDBC dialect could use regexp for parsing parameters from message/description. Theoretically, it can break the regexps.

And if we pass the quoting values to an JDBC dialect, it can throw some Spark exception which performs quoting inside like PostgresDialect throws NonEmptyNamespaceException. The last one does quoting inside its constructor. Apparently, we will get double quoting values which is a bug already.

[MaxGekk]

Merging to master. Thank you, @cloud-fan for review.