feat(core): support batch+parallel edges traverse

[DanGuge]

Purpose of the PR

• Support batch processing and concurrent execution using multiple threads
  • KoutTraverser & KneighborTraverser
• [Feature Summary] Enhancement and optimization OLTP algorithm & api #2276

Main Changes

• Enhance Consumers.java, supporting ExceptionHandle and Future to handle InterruptedException when awaiting
• Add Nested Iterator Edge and support batch execution
• Support batch execution & thread parallel in KoutTraverser and Kneighbor
• design document

Verifying these changes

• Trivial rework / code cleanup without any test coverage. (No Need)
• Already covered by existing tests, such as (please modify tests here).
• Need tests and can be verified as follows:
  • Postman Test & Runtime Log: the tests of Kout Post are shown below

Initialize the Graph

• Initialze the graph according to the link

Add LOG in consumer

Postman Test & Check Log

• About correctness, we conducted multiple sets of serial and parallel comparison tests and found no differences
• About parallel acceleration, there is no significant acceleration due to the lack of larger levels of test data

Does this PR potentially affect the following parts?

• Nope
• Dependencies (add/update license info)
• Modify configurations
• The public API
• Other affects (typed here)
  • Traverser execution logic

Documentation Status

• Doc - TODO
• Doc - Done
• Doc - No Need

[codecov]

Codecov Report

Merging #2312 (23f48ca) into master (4ceef1a) will decrease coverage by 0.23%.
The diff coverage is 70.61%.

@@             Coverage Diff              @@
##             master    #2312      +/-   ##
============================================
- Coverage     68.26%   68.04%   -0.23%     
+ Complexity      989      981       -8     
============================================
  Files           500      501       +1     
  Lines         41516    41662     +146     
  Branches       5786     5796      +10     
============================================
+ Hits          28342    28350       +8     
- Misses        10415    10556     +141     
+ Partials       2759     2756       -3     

Files Changed	Coverage Δ
...che/hugegraph/traversal/algorithm/steps/Steps.java	49.12% <0.00%> (-2.67%)	⬇️
...main/java/org/apache/hugegraph/util/Consumers.java	51.95% <42.85%> (-4.90%)	⬇️
...e/hugegraph/traversal/algorithm/OltpTraverser.java	68.00% <74.71%> (+3.82%)	⬆️
...egraph/traversal/algorithm/KneighborTraverser.java	79.54% <76.19%> (-3.79%)	⬇️
...he/hugegraph/backend/query/EdgesQueryIterator.java	78.57% <78.57%> (ø)
...e/hugegraph/traversal/algorithm/HugeTraverser.java	51.91% <81.25%> (-7.57%)	⬇️
...e/hugegraph/traversal/algorithm/KoutTraverser.java	58.42% <96.15%> (+1.28%)	⬆️
...in/java/org/apache/hugegraph/task/TaskManager.java	74.69% <100.00%> (-1.86%)	⬇️
.../traversal/algorithm/records/KneighborRecords.java	91.66% <100.00%> (+2.19%)	⬆️
.../hugegraph/backend/store/rocksdb/RocksDBStore.java	73.46% <100.00%> (ø)

... and 17 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[javeme]

Nice enhance

[javeme]

can we remove VWrapper class and just use new Object() instead

[DanGuge]

QUEUE_END will be put at the end of BlockingQueue<VWrapper<V>> queue, so it will be cast to VWrapper<V>.

If we just use new Object() instead, we will get the exception below.

[javeme]

get it, can we remove VWrapper class and keep BlockingQueue<V> queue, then try to define V QUEUE_END = (V) new Object();

[imbajin]

could use ldbc data to perf it (u could the instruction in ldbc-feishu-doc)

[javeme]

get it, can we remove VWrapper class and keep BlockingQueue<V> queue, then try to define V QUEUE_END = (V) new Object();

[javeme]

LGTM