Set explain attributes after the query is prepared

[abhishekrb19]

In this PR:

• Set the explain plan attributes after the query is prepared, when we've the finalized output names in rootQueryRel. This also gives us the benefit of going through all validation checks in the prepare phase.
• Simplify resolveClusteredByColumnsToOutputColumns function for explain attributes as things are already validated and we just have one source list, rootQueryRel, containing the output column names; the existing unit tests work right out of the box. Added new unit tests using JOIN and WITH...AS to prove that the logic no longer depends on individual SqlNode types.
• Add a negative ordinal check for clustered by columns as a workaround to Calcite's limitation; added unit tests to validate this.

Key changed/added classes in this PR

• DruidSqlParserUtils.java
• QueryHandler.java
• DruidSqlParserUtilsTest.java
• CalciteInsertDmlTest.java

This PR has:

• been self-reviewed.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• been tested in a test Druid cluster.

[gianm]

This change would make the "explain clustered by" feature work in more cases, but it definitely still won't work in all cases, and IMO we don't want to make the entire EXPLAIN statement blow up if we can't figure out the clustered by columns. So, I think we should go in one of two directions for this work:

1. Figure out a way to make the "explain clustered by" feature always work, which might potentially involve moving this logic somewhere else, or refactoring something.
2. Embrace that it might not always work, and have that not fail the EXPLAIN, but instead return some kind of signifier in the response that we can't figure out the clustered-by columns. Callers would need to look at that to be able to differentiate "no clustered by" from "can't figure out clustered by".

[abhishekrb19]

@gianm, thanks for the review. Yes, I went ahead with 1 -- moving this logic to after the query is prepared enables us to extract the necessary output columns from rootQueryRel always - instead of relying on the different SqlNode types in the pre-prepare phase. Another benefit of doing it after the query preparation phase is that it already goes through the validation checks. IMO, the code looks simpler.

[zachjsh]

🚀