[WIP] Fix inconsistencies and refactor primitive types in parser

[mihailom-db]

What changes were proposed in this pull request?

This PR proposes a change in how our parser treats datatypes. We introduce types with/without parameters and group accordingly.

Why are the changes needed?

Changes are needed for many reasons:

1. Context of primitiveDataType is constantly getting bigger. This is not a good practice, as we have many null fields which only take up memory.
2. We have inconsistencies in where we use each type. We get TIMESTAMP_NTZ in a separate rule, but we also mention it in primitive types.
3. Primitive types should stay related to primitive types, adding ARRAY, STRUCT, MAP in the rule just because it is convenient is not good practice.
4. Current structure does not give option of extending types with different features. For example, we introduced STRING collations, but what if we were to introduce CHAR/VARCHAR with collations. Current structure gives us 0 possibility of making a type CHAR(5) COLLATE UTF8_BINARY (We can only do CHAR COLLATE UTF8_BINARY (5)).

Does this PR introduce any user-facing change?

No. This is internal refactoring.

How was this patch tested?

All existing tests should pass, this is just code refactoring.

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

No.

[mihailom-db]

@MaxGekk @cloud-fan Could you take a look at this PR? We should aim to keep our parser in the most readable and most efficient state.

[MaxGekk]

what if we get an unsupportedType with a suffix like: TIME WITH TIME ZONE?

[mihailom-db]

Yeah, this potentially can make a problem. I mean, we would probably return a bad error message. Let me think if we can scope issues like this as well.

[mihailom-db]

Actually error message will stay the same, even previously we would return syntax error. The only thing here is if we want to improve the error messages a bit further?

[cloud-fan]

should this be primitiveTypeWithoutParameters?

[mihailom-db]

It can go, but in this case I would say collation is a parameter as well. It can change it's value to some different value not known at parsing time. If we follow this case, then probably INTERVAL should go to primitiveTypeWithoutParameters, as it is actually without parameters.

[mihailom-db]

By not known at parsing time, I mean identifier/arbitrary value.