Validation of join predicate should verify that the table operand is the key

[rodesai]

We should validate that the table operand of the join predicate is the table's key column. KSQL cannot guarantee correctly computed joins if the table operand is a non-key column. Table records with matching values for the column may be assigned to different partitions from the stream. It also usually doesn't make semantic sense to do this. The only exception would be where the column is an alternate key for the table. Even then we can't repartition to handle the join because there is no way for KSQL to guarantee ordering, or for the user to specify that the other column is partitioned the same as the declared key (which would make ordering a non-issue).

[apurvam]

This is related to #749

[big-andy-coates]

This would be potentially expensive to check on each record. An alternative semantics for WITH (Key='foo') is discussed in #804 that does away with this issue.

[rodesai]

@big-andy-coates this is something we should check when building the topology. Its orthogonal to the semantics we have for expressing what the key column is. However that works, we should still fail requests to start queries that try to join with a column thats not the key.

[rmoff]

@rodesai are you ok to close this and track in #749 ? Or visa versa, I don't mind :)

[rodesai]

@rmoff this is a different issue. #749 covers the case where the kafka message key has a different format than the key column. This issue covers raising an error if the join predicate references a column that is not the table key.