[CALCITE-7781] Improve identifier and literal handling in SQL dialects and adapters

[rubenada]

Jira Link

CALCITE-7781

Changes Proposed

Improve identifier and literal handling in SQL dialects and adapters:

• Backslash escaping in dialects: BigQuery, Firebolt, ClickHouse, Hive, Spark, Snowflake, Infobright, Netezza, and default ansi (with system property to go back to legacy behavior for the last one).
• Improve identifier verification in Geode, ElasticSearch, MongoDB, Cassandra, and Splunk adapters.

[rubenada]

Direct documentation references for backslash-escaping behaviors across all 8 impacted SQL dialects:

1. BigQuery
   Source: Google Cloud BigQuery Lexical Structure Documentation
   "Quoted strings enclosed by single (') quotes can contain unescaped double (") quotes, as well as the inverse. Backslashes () introduce escape sequences."

2. ClickHouse
   Source: ClickHouse Syntax Reference Documentation
   "In string literals, you need to escape at least ' and \ using escape codes ' (or: '') and \."

3. Firebolt
   Source: Firebolt Data Types Documentation
   "String literals will also recognize backslash escape sequences."

4. Apache Hive
   Source: Apache Hive LanguageManual Types (Literals)
   "String literals can be expressed with either single quotes (') or double quotes ("). Hive uses C-style escaping within the strings."

5. Spark SQL
   Source: Apache Spark SQL Reference – Literals Documentation
   "Use \ to escape special characters (e.g., ' or )."

6. Snowflake
   Source: Snowflake SQL Reference - Pattern Matching & String Functions
   "If you are using a regular expression in a single-quoted string constant, you must escape any backslashes in backslash-sequences with a second backslash."

7. Netezza
   Source: IBM Netezza / Netcool Documentation – Escape Codes
   "Note: The escape sequences for backslash, single quote, and double quote should be double-escaped. For example, to send a backslash character () use \\."

8. Infobright
   Infobright is built directly on the MySQL engine framework (Infobright Enterprise Edition / IEE) and inherits MySQL's string lexing rules, which process backslash escape sequences in string literals by default.
   Source: MySQL 8.0 Reference Manual – String Literals (Applies to Infobright's engine parser)
   "MySQL recognizes the escape sequences in string literals... \ An ASCII 92 backslash character."

[mihaibudiu]

I left a few comments.
I trust that your research is correct, I didn't verify the rules for each dialect.

[rubenada]

Thanks for the review @mihaibudiu
I tried my best on the impacted dialects and adapters (even though I might not be an expert on them).
The truth is that, sometimes, contributors volunteer to add new adapters, but then this code is hardly maintained, so it's up to the "regular contributors/maintainers" to fix / improve some code that we are not very familiar with.
In any case, this PR impacts mostly edge cases for escaping scenarios, no major changes are present.

[rubenada]

@mihaibudiu do you agree with the review commit? Do you have any other remarks?

[mihaibudiu]

I have approved, my comments were mostly cosmetic, not about the core implementation.

[sonarqubecloud]

Quality Gate passed

Issues
11 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud