Make scan limit error more friendly.

[Shylock-Hg]

What type of PR is this?

• bug
• feature
• enhancement

What does this PR do?

Which issue(s)/PR(s) this PR relates to?

Close #3492

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

Additional context/ Design document:

Checklist:

• Documentation affected (Please add the label if documentation needs to be modified.)
• Incompatibility (If it breaks the compatibility, please describe it and add the corresponding 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:

                                                            `

[czpmango]

Why do we need this limitation on vertex/edge scans when we already have slow query management?

[czpmango]

These error messages are really not friendly and are implementation-specific.

[wey-gu]

It seems this scan limit error now overrides the index not existed case, which is not expected if I understand it correctly. update: Aha, now I understand that we introduced scan and enforced user to give a limit filter(for pushdown). ;) Thanks, this is a big move in UX!

(root@nebula) [amundsen]> MATCH (table_node:Table) return count(table_node) as number_of_tables
[ERROR (-1005)]: Scan vertices must specify limit number.

Sat, 25 Dec 2021 19:30:03 CST

(root@nebula) [amundsen]> CREATE TAG INDEX Table_index on Table();
Execution succeeded (time spent 2003/26690 us)

Sat, 25 Dec 2021 19:32:36 CST

(root@nebula) [amundsen]> REBUILD TAG INDEX Table_index
+------------+
| New Job Id |
+------------+
| 4          |
+------------+
Got 1 rows (time spent 3182/18671 us)

Sat, 25 Dec 2021 19:32:59 CST

(root@nebula) [amundsen]> MATCH (table_node:Table) return count(table_node) as number_of_tables
+------------------+
| number_of_tables |
+------------------+
| 6                |
+------------------+

[Shylock-Hg]

Why do we need this limitation on vertex/edge scans when we already have slow query management?

According to @CPWstatic 's suggestion, avoid user's mistake.