fix: the QTTs now run through SqlFormatter & various other formatting fixes

[agavra]

Co-authored-by: Sergio Peña [email protected]

Description

This reinstates #3037 into the current code path for the new testing tool. It also fixes some issues:

• SqlFormatInjector was allowing statements that cannot be parsed to go through in order to appease some tests. This is no longer the case
• SqlFormatter adds some formatting for statements that don't need it, but go through the testing path
• fix: create persistent queries fail with reserved words #3216 is applied (thanks @spena co-authored)
• SqlFormatter now properly escapes identifiers nested in structs
• ensure-formatter.json was added to make sure that a future refactor does not skip this code path

Testing done

• unit testing
• ensure-formatter.json

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[spena]

It looks good.

I just left a question in the QTT test. I'm not sure how to interpret a possible failure on that test. Why would it fail if the SqlFormatter is not called?

[spena]

I could not understand why this could fail. Could you explain in the comment what can go wrong that would make this to fail? I see a CREATE command which will be persisted in the command topic. How can this fail if the SqlFormatter is not called?

[agavra]

it's a little hacky, but SET calls fail to format (they're not supported in SqlFormatter). This test makes sure that a failure does happen. Without running through the SqlFormatter, a different failure happens - not ("Unable to format statement!")