feat: Implement RegionScanner for SeqScan

[evenyag]

I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

• Support parallel scan in mito engine #2806
• This relies on feat: Implements row group level parallel unordered scanner #3992

What's changed and what's your intention?

This PR implements RegionScanner for SeqScan.

• It changes the definition of ScanPart so it can represent the time range of the part and keeps ranges from different files separately.
• It moves StreamContext and ScanPartList to the scan_region mod so we can reuse it in SeqScan.
• Adds SeqDistributor to organize parts for parallel scan
  • It groups parts by their time range and yields parts with non-overlapping ranges
  • If the number of ranges to scan is greater than parallelism, it merges small ranges

If there are multiple files to read in a time range, it will spawn a task to read each file. The parallelism is limited by a semaphore in the scanner.

Checklist

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR requires documentation updates.

[codecov]

Codecov Report

Attention: Patch coverage is 91.52542% with 45 lines in your changes missing coverage. Please review.

Project coverage is 85.17%. Comparing base (587e99d) to head (09ad54a).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4060      +/-   ##
==========================================
- Coverage   85.46%   85.17%   -0.30%     
==========================================
  Files         994      994              
  Lines      174348   174947     +599     
==========================================
  Hits       149005   149005              
- Misses      25343    25942     +599     

[fengjiachun]

LGTM

[waynexia]

If there are multiple files to read in a time range, it will spawn a task to read each file. So the number of parallel tasks may be greater than parallelism.

This seems to be a risky thing. Can we add some indirect layer like a queue or something else to take back the control of parallelism?

[evenyag]

This seems to be a risky thing. Can we add some indirect layer like a queue or something else to take back the control of parallelism?

There is already a semaphore to control the parallelism of reading files.