Scan cursor has unreasonable config

[Nicole00]

this issue appear after #3262.

1. The scan request requires the client to explicitly set the has_next in the request ScanCursor to true, which is unreasonable. The value of has_next should not allow the client to parameterize.

2. When client call scan interface for the first time, client needs to set next_cursor to "".getBytes to scan from the beginning. I suggest to change "".getBytes to null， then clients will not need to explicitly set the next_cursor.

[Shylock-Hg]

You could set has_next to false.

[Nicole00]

You could set has_next to false.

What's the meaning for client to set has_next to false.

[Shylock-Hg]

You could set has_next to false.

What's the meaning for client to set has_next to false.

No cursor.

[Nicole00]

You could set has_next to false.

What's the meaning for client to set has_next to false.

No cursor.

null scanCurosr can mean no cursor, why need client to explicitly set has_next.

[Shylock-Hg]

You could set has_next to false.

What's the meaning for client to set has_next to false.

No cursor.

null scanCurosr can mean no cursor, why need client to explicitly set has_next.

Just follow the origin interface.

[Nicole00]

You could set has_next to false.

What's the meaning for client to set has_next to false.

No cursor.

null scanCurosr can mean no cursor, why need client to explicitly set has_next.

Just follow the origin interface.

But in the origin interface, client does not need to set has_next.

[Shylock-Hg]

You could set has_next to false.

What's the meaning for client to set has_next to false.

No cursor.

null scanCurosr can mean no cursor, why need client to explicitly set has_next.

Just follow the origin interface.

But in the origin interface, client does not need to set has_next.

Ok, it's my fault. Now we should set it in request.

[jievince]

auto ret = plan.go(partId, cursor.get_has_next() ? *cursor.get_next_cursor() : "");

If has_next is true but next_cursor is not set, it'll cause storaged to crash. So you always need to check if next_cursor is set.

[Shylock-Hg]

auto ret = plan.go(partId, cursor.get_has_next() ? *cursor.get_next_cursor() : "");

If has_next is true but next_cursor is not set, it'll cause storaged to crash. So you always need to check if next_cursor is set.

Yes, maybe we could remove has_next