coltypes: refactor colexec types

[yuzefovich]

Our current type system used in the vectorized engine has a big disadvantage:

• it is "lossful" - doing the conversion of types.T -> coltypes.T -> types.T will not always return the same type that it is started with.

This will very likely (if not already) cause issues and additional burden when we need to specialize the behavior of an operation based on the "actual" types.T type of a column, but we might not have that information anymore.

We should fix it. One idea that Jordan mentioned (which I agree with) is that coltypes should be an extension of normal types that will also hold a "physical type" - the way we represent it in Go.

[yuzefovich]

I prototyped two approaches of resolving this issue.

At first I started implementing different "vectorized execution" type system in which a type would be coltypes.T ("physical" part) but also would store the reference to the original "logical" type types.T. The idea was that everything in colexec package would be using the new type system. I reached a few hiccups along the way:

• not all types are exported from sql/types package, so the conversion from types.T to colexectypes.T seemed pretty painful to write correctly
• vectorized execution planning operates on the specs that contain []types.T
• we still would need to do a lot of plumbing to put the new types into the operators because coltypes should not care about those (and I appreciate Dan's move of that package outside of colexec, otherwise it would have been tempting to put the "logical" sql type into the "physical" type)
• we already have two type systems that fully satisfy our needs, and the root of the problem is actually missing necessary plumbing.

The last point made me realize that we do not, in fact, want a new type system - we simply need to put the logical type information during the execution planning, and that's what I did in #43723.

[yuzefovich]

I spent some more time thinking about this, and now I'm leaning towards us using SQL logical types pretty much everywhere in the vectorized engine (i.e. in the operators, during planning, during serialization) and performing types.T -> coltypes.T conversion "in the last moment possible" (whatever that might be). We will still be generating templated code based on coltypes.T though.

Such change will allow us to implement coltypes.Datum for all unoptimized logical types and will solve the problem of lossful conversion since original logical types will be always available. One of the main arguments in favor of this decision is that we need to come up with a way to serialize Datums of any logical type, so we will need to have access to the logical type "deep down, in the heart of the vectorized engine" anyway.

[yuzefovich]

After discussing with Archer and Alfonso, we agreed that plumbing logical types down everywhere is definitely required to get coltypes.Datum for all unoptimized types working. I'll take a stab at it by replacing the usage of coltypes.T by using the logical types wherever possible (the exception being the places where we're touching the physical representation - probably in Allocator object and in overload resolution). I'll also try changing the way we template binary and comparison expressions (currently we copy-paste the code from eval.go - which makes sense to do for the optimized types, but not for all others).

[yuzefovich]

The current status of this issue is that we have plumbed logical types into the operators, and the next step is to remove coltypes.T entirely - this requires changing the way we generate code from templates, and I'm currently looking into that.