Refactor go planner

[nevermore3]

What type of PR is this?

• bug
• feature
• enhancement

What problem(s) does this PR solve?

Issue(s) number:

close https://github.com/vesoft-inc/nebula-ent/issues/2532

Description:

yield 'Tim Duncan' as a | go 3 steps from $-.a over like where like.likeness > 30 yield edge as e

previous plan

current plan

Due to the existence of the loop operator in the previous plan, the data flow and dependencies were inconsistent, so many optimization rules could not be applied, such as filter pushdown, merging projects, and so on.

in the new plan. the go statement is divided into two operators, expand and expandall, expand is responsible for expansion, and expandAll is responsible for the expansion process to obtain the attributes required by the user

BEFORE:

(root@nebula) [nba]> yield 'Tim Duncan' AS id| go 100 steps from $-.id  over * bidirect yield edge as e|yield count(*)
+----------+
| count(*) |
+----------+
| 486      |
+----------+
Got 1 rows (time spent 3178857/3188150 us)

NOW:

(root@nebula) [nba]> yield 'Tim Duncan' AS id| go 100 steps from $-.id  over * bidirect yield edge as e|yield count(*)
+----------+
| count(*) |
+----------+
| 486      |
+----------+
Got 1 rows (time spent 209215/209876 us)

the yellow line is the optimized version
the blue line is the master version

How do you solve it?

Special notes for your reviewer, ex. impact of this fix, design document, etc:

Checklist:

Tests:

• Unit test(positive and negative cases)
• Function test
• Performance test
• N/A

Affects:

• Documentation affected (Please add the label if documentation needs to be modified.)
• Incompatibility (If it breaks the compatibility, please describe it and add the label.）
• If it's needed to cherry-pick (If cherry-pick to some branches is required, please label the destination version(s).)
• Performance impacted: Consumes more CPU/Memory

Release notes:

Please confirm whether to be reflected in release notes and how to describe:

ex. Fixed the bug .....