Optimize produce request handler

[BewareMyPower]

Motivation

There're some problems with produce performance.

The main problem is the pending produce queue. It holds multiple pending produce requests (PendingProduce), which wait until PersistentTopic is ready and the MemoryRecords is encoded. First, PendingProduces wait for different futures of PersistentTopic. Second, encoding MemoryRecords is fast so that putting it to another thread is not necessary and could cause some performance overhead.

Modifications

1. Encoding MemoryRecords in the same thread of handleProduceRequest.
2. Check if the CompletableFuture<PersistentTopic> is done.
   • If it's done, just publish the messages directly without pushing the pending produce requests to the queue.
   • Otherwise, reuse the previous CompletableFuture<PersistentTopic>. This trick is performed by PendingTopicFutures, which uses the previous CompletableFuture<PersistentTopic> by thenApply or exceptionally.
3. Add tests for PendingTopicFutures.
4. Use a map of partition and response instead of a map of partition and response future in handleProduceRequest.

[BewareMyPower]

Here's a performance compare with 200 MB/s throughput on a topic with 16 partitions.

The blue line is the result of this PR. Though there're still some jitters, the result is much better than before.

[BewareMyPower]

The Codacy check failed because the original code that is removed in this PR can't pass the check, just ignore it.

[BewareMyPower]

The DistributedClusterTest may fail, I'll take a look.