Add macros $__adhoc_column

[Smelentyev]

Summary

Fixes an issue where ad hoc filters fail when executing long or complex ClickHouse queries.
Previously, ad hoc filtering could time out or mis-handle large SQL statements, especially when the filter variable contained multiple conditions.
This change adjusts query handling to properly support long query strings by improving SQL parsing and execution logic.

What this PR does

• Fixes handling of ad hoc queries with long SQL expressions.
• Includes tests ensuring correct behavior for complex filters.

How to test

1. Set clickhouse_adhoc_query =

SELECT DISTINCT $__adhoc_column
FROM database.table
WHERE $__timeFilter(timestamp)
LIMIT 1000

3. Create an ad hoc variable with a long SELECT DISTINCT query (e.g., filtering over multiple joined tables).
4. Use that variable in dashboard panels.
5. Verify that filters are correctly applied and queries execute without timeout or truncation.

Related issues

Fixes #1490

Notes

This change should enhance stability and user experience for dashboards using ad hoc filters on large tables.

[CLAassistant]

All committers have signed the CLA.

[bossinc]

Adhoc filters are a little unreliable with complex queries. We have been discussing using a CH abstract syntax tree that would be able to be "smarter" with the placement of adhoc clauses.

I do not think we want to go this direction because adhoc filters are supposed to work without modifying your queries. If we implement an $__adhoc_column macro and, in the future we fix adhoc queries, we would never be able to deprecate this macro without requesting users to edit their queries.

I am wondering what advantage adding $__adhoc_column has over using template variables.
It appears that the functionality of $__adhoc_column can be achieved currently with template variables. What is the advantage of adding $__adhoc_column over template vars?

Thank you for creating this PR and thinking of ways adhoc filters can be better!

[Smelentyev]

The problem is described in #1490.
We couldn't solve it using variables because when the list of possible options is generated, we don't know which column was selected in the ad hoc filter.

If you could suggest how to implement this using existing tools, that would be great.

[bossinc]

@Smelentyev I see what you mean now. I think the reason this was removed is that parsing the table does not always work and we were hoping the adhoc filters could be changed by Grafana to better support this use case. We are discussing internally other ways this problem might be solved.