MLIR: support CALL of registered procedures end to end

[rjb32]

Runs a Cypher CALL of a registered procedure through the MLIR engine, from the frontend down to the interpreter.

A procedure that declares a row-aligned argument now has to report the input row of the rows it emits: registration refuses one that does not, and an argument read once per call rather than per row is declared as constant.

Works today:

// a call is the whole query
CALL db.labels() YIELD id, label RETURN id, label

// no YIELD: every return value the procedure declares is emitted
CALL db.labels()

// a procedure declaring no return value, driven for its effect alone
CALL test.sideEffect()

// YIELD renames what the query reads, and may take a subset of the return values
CALL db.history() YIELD commit AS commitHash, nodeCount, edgeCount, partCount
RETURN commitHash, nodeCount, edgeCount, partCount

// YIELD ... WHERE filters the rows the call emitted
CALL db.labels() YIELD label WHERE label = 'Manager' RETURN label

// correlated: the matched node is the argument, and rides through the call
MATCH (n) CALL test.nodeScore(n) YIELD score RETURN n, score

// the matched node rides through the call even where the projection drops it: every
// column in flight is carried, which the procedure's input-row report is what allows
MATCH (n) CALL test.doubleNodeID(n) YIELD doubled RETURN doubled

// uncorrelated after a MATCH: the call is crossed with it
MATCH (n) CALL db.labels() YIELD label RETURN n, label

// several yields off one call, here two lists
MATCH (n) CALL test.nodeTags(n) YIELD tags, coords RETURN n, tags, coords

// chained calls, the second's WHERE reading what the first yielded
MATCH (n) CALL test.expandNodeID(n) YIELD copy
          CALL test.fanOutNodeID(n) YIELD value WHERE copy > 100 RETURN value

// one call per end of a traversal, projecting an expression over both yields
MATCH (n)-->(m) CALL test.expandNodeID(n) YIELD copy AS x
                CALL test.fanOutNodeID(m) YIELD value AS y RETURN x + y

// chained calls and no MATCH: the first opens the dataflow, and its yield is both the
// next call's argument and carried on past it
CALL test.twoNodes() YIELD id
CALL test.expandNodeID(id) YIELD copy
CALL test.fanOutNodeID(id) YIELD value
RETURN id, copy, value

// three calls reading nothing of each other, so all three are crossed
CALL test.twoNodes() YIELD id AS a
CALL test.twoNodes() YIELD id AS b
CALL test.twoNodes() YIELD id AS c
RETURN a, b, c

Added a test for GNN-like sampling:

MATCH (n:Seed)
CALL gnn.neighbourhoodSample(n, 3, 42)     YIELD tgt AS hop1
CALL gnn.neighbourhoodSample(hop1, 2, 42)  YIELD tgt AS hop2
CALL gnn.neighbourhoodSample(hop2, 2, 42)  YIELD tgt AS hop3
RETURN n, hop1, hop2, hop3

Added a test for a call crossing and a call joining a hop chain:

CALL test.firstNodes(2) YIELD person
MATCH (person)-->(m)
MATCH (m)-->(z)
CALL test.offsetPair(17) YIELD offset
RETURN person, z, offset

CALL test.firstNodes(2) YIELD person AS a
MATCH (a)-->(m)
CALL test.firstNodes(3) YIELD person AS z
MATCH (m)-->(z)
RETURN a, m, z

[cyrusknopf]

I do this slightly differently in #754 , we should compare and see which pattern we want

[cyrusknopf]

What are "those" columns?

[rjb32]

Removed

[cyrusknopf]

If I understand correctly this comment can be simplified to: "a column is live if it is defined in the current block"

[rjb32]

Done

[cyrusknopf]

Can we have some example NL and DB programs as samples in samples/mlir?

[rjb32]

Done

[cyrusknopf]

Do we want separate logic for cross product of a MATCH and a CALL? Ideally I would want centralised cross product logic to join islands regardless of whether they are from a MATCH or a CALL. I think it would involve maintaining CALLs in the connected components (we already tracked connected components in generateTraversal

[rjb32]

Yes it would be a better shape to have one unified procedure for the cross product.
But today in this PR, the cross product is decided before CALL statements are processed, in generateTraversal. So this is where it would require integration of the CALLs with the VDG to use the same logic based on components identification in the VDG. For now we do codegen of calls afterwards to minimise changes to the VDG until we can come with a better approach.

[cyrusknopf]

Verbose

[rjb32]

Done

[cyrusknopf]

I think this could benefit from being split onto a few lines

[rjb32]

Done