fix some rocksdb api will fail in PlainTable

[critical27]

What type of PR is this?

• bug
• feature
• enhancement

What problem(s) does this PR solve?

Issue(s) number:

Description:

This problem is found in nebula-ng. Some of our rocksdb api is not well verified in PlainTable, for example, whether the data is in sst will effect the api result. The main problem is that:

1. Since PlainTable only support prefix-based Seek, we need to specify prefix_same_as_start not only in prefix, but also range and rangeWithPrefix.
2. And the length of prefix_extractor need to be modified. Because within PlainTable, if the prefix bloom filter is not inserted, you can't be read by prefix any more. So to make sure every data could be read, we use the minimum length we use in prefix, which is 4.

This is a simple way to fix the problem. In nebula-ng, I will consider refactor it a bit.

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:
Not related.

[SuperYoko]

So prefix_same_as_start & extractorLen_ together decide the behavior? And only in plaintable?

[critical27]

PlainTable must use prefix-based Seek, so we must set prefix_same_as_start = true;
And for BlockBasedTable, if we have prefix extractor, we just use total_order_seek for simplicity, otherwise we need to judge whether the parameter is longer than extractor length (the way we use in prefix function)

[SuperYoko]

LGTM.

[wenhaocs]

GJ

[critical27]

Don't merge it plz, the funny part is that this will fail in ubuntu2004-clang, but other env will pass. I need to check it later