Better RequestProcessor pipeline

[lzydmxy]

The current RequestProcessor pipeline can be roughly abstracted into the following three steps:

while (true)
{
    1.move request from requests_queue to pending_queue
    2.do read from all pending_queue until got write request
    3.handle commit_requests
}

The current pipeline has two problems:

1. A high read batch size will delay commit processing
   2.Read requests can also delay. Imagine we have a session with a write request and a read request. In the step third, we process the write request . After that, we move to step one, If there are a large count of read requests from other sessions, it can cause the read request in this session to be suspended for a long time.

Describe your idea

New pipeline

while (1)
{
    1.move request from requests_queue to pending_queue(if got any write request), or just do read async parallelism (until reach maxReadBatchSize)
    2.wait all read done
    3.handle commit_requests, and need_drain.push_back(commit_requests.session_id)
    4.handle need_drain sessions, do read async parallelism
}

1. We need max number of reads to process from queuedRequests before switching to processing commits
2. When handling commit requests, record the corresponding session ID so that we can promptly address the read requests that are suspended due to the write requests.
3. Do readings async parallelism