feat: expression support for PARTITION BY

[agavra]

fixes #4018

Description

This change allows for arbitrary expression support for PARTITION BY expressions:

• use CodeGenRunner to evaluate the partition by expression instead of the legacy way which had custom handling for column references
• have partition by go through proper rewriting (to make it consistent with other expressions, e.g. adding alias)

Note that if a partition by expression is used, the rowkey will not correspond to any column in the value.

Testing done

• new unit tests
• updated QTT tests

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 #")

[rodesai]

Mostly LGTM. One issue raised inline.

[rodesai]

I don't think comparing with the ROWKEY is actually safe, e.g.:

CREATE STREAM LEFT (A STRING, B STRING) WITH (KEY='A');
CREATE STREAM RIGHT (C STRING, D STRING) WITH (KEY='C');
CREATE STREAM JOINED AS SELECT LEFT.*, RIGHT.* FROM LEFT JOIN RIGHT ON L.B=R.D PARTITION BY LEFT.ROWKEY;

In this case, when we hit the repartition, the stream will be partitioned on B/D, so we do want to repartition, even though the column ref is ROWKEY.

[agavra]

cc @big-andy-coates - I think @rodesai brings up a good point here, though I think it's an existing bug. I think we should fix it in the short-term by re-introducing the "unnecessary" repartition step in the case of isRowKey but before I do that I wanted to run it past you since you implemented the original optimization (#2735).

[big-andy-coates]

I'd suggest adding this as a QTT test to ensure we're handling this correctly. Do what you need to do to get this functionally working.

Raise a github issue to track the outstanding piece.

I think we can clean this up once we have cleaner code around the handling of schemas and duplicating ROWKEY and ROWTIME into the value schema.

Specifically, once we clean up / remove the use of source-aliases on schema fields and have arbitrary key column names, then I think this will be easy to solve because the ROWKEY name won't be ambiguous.

[agavra]

f8bfefa - I will fix this in a future PR

[agavra]

#4053

[rodesai]

LGTM