Index planning can match against nested synthetic type primary key components incorrectly

[alecgrieser]

There are cases where during index planning, we can match against the primary key components of a synthetic record type in a way that is incorrect.

For example, suppose you had a stored record type with primary key (a, b). Then you had a synthetic record type with a constituent "c1" of that type and another constituent "c2" on a different type. Then you had a query like:

Query.and(
    Query.field("c2").matches(Query.field("x").equalsParameter("xParam"),
    Query.field("c1").matches(Query.field("a").equalsParameter("aParam")
)

If you had an index on field("c2").nest("x"), then the planner can end up trying to plan that as a scan on the range:

[EQUALS $xParam, IS syntheticType, EQUALS $aParam]

Using the keys in the index, and then matching against the primary key fields of the record. That's not quite right, though, because the constituent primary keys are actually nested, which have a different representation. So, the EQUALS $aParam instead of comparing the first column of c1's primary key to $aParam (the desired behavior) will compare the entire primary key to $aParam, which is incorrect.