Recursive path

[andyfengHKU]

This PR keeps track of path (currently implemented as LIST[INTERNAL_ID]) for recursive join

[codecov]

Codecov Report

Patch coverage: 98.55% and project coverage change: +0.11 🎉

Comparison is base (9d7a4d7) 91.84% compared to head (42d39ef) 91.96%.

❗ Current head 42d39ef differs from pull request most recent head 875a0d8. Consider uploading reports for the commit 875a0d8 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1538      +/-   ##
==========================================
+ Coverage   91.84%   91.96%   +0.11%     
==========================================
  Files         689      691       +2     
  Lines       24670    24616      -54     
==========================================
- Hits        22659    22638      -21     
+ Misses       2011     1978      -33     

Impacted Files	Coverage Δ
...inder/bind_expression/bind_function_expression.cpp	98.34% <ø> (-0.08%)	⬇️
...inder/bind_expression/bind_property_expression.cpp	84.44% <ø> (-6.86%)	⬇️
src/include/binder/expression/expression.h	91.66% <ø> (-0.93%)	⬇️
src/include/binder/expression_binder.h	100.00% <ø> (ø)
...de/processor/operator/recursive_extend/bfs_state.h	94.33% <91.66%> (-5.67%)	⬇️
src/binder/bind/bind_graph_pattern.cpp	94.32% <100.00%> (ø)
...inder/expression/existential_subquery_expression.h	100.00% <100.00%> (ø)
src/include/binder/expression/node_expression.h	100.00% <100.00%> (ø)
...rc/include/binder/expression/node_rel_expression.h	100.00% <100.00%> (ø)
...c/include/binder/expression/parameter_expression.h	100.00% <100.00%> (ø)
... and 12 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[semihsalihoglu-uw]

As per our discussion, I would still improve on these:

1. Try to implement a iterative version that also can write multiple paths into ValueVectors inside the FixedLengthPathScanner. You might want to benchmark these optimizations to see if they matter but they're common wisdom I think.
2. I would add more comments to clarify how the entire algorithm will work. You would need to clarify that: (i) Why do you need multiple FixedLengthPathScanners? (ii) where you go over multiple FixedLengthPathScanners? and (iii) More comments inside the FixedSizePathScanner::getNext() function to clarify the high-level logic.

Also, it would be good to have @anuchak review the PR too. It would help him familiarize himself and see our discussions.