**Summary**
After upgrading a host that is just a collection `Distributed` tables to 20.4.X and 20.5.2.7, we observe the new `MemoryTracking` setting increasing substantially during writes, leading to individual writes and reads yielding exceptions: ```Memory limit (total) exceeded: would use 28.28 GiB (attempt to allocate chunk of 4197840 bytes), maximum: 28.28```

System metrics show that no actual memory is being allocated to the same size.
<img width="993" alt="Screen Shot 2020-07-19 at 12 23 59 PM" src="https://user-images.githubusercontent.com/1189446/87883721-229e7280-c9be-11ea-851b-0e1511cc10bb.png">

Please let me know if there is any additional context, diagrams, or statements I should provide. I'm interested in knowing how to correlate the total `MemoryTracking` metric to anything else since system memory does not reflect the metric at all.

**Context**
This host has four different `Distributed` tables that are written to via the HTTP interface with `insert_distributed_sync=1` set.
The host itself has no local tables.

The hosts with the downstream local tables are all 20.5.2.7.

We have downgraded the `Distributed` host in question back to 20.3.9.70 in order to continue writing to the clusters.
*
 * This stream has three kinds of threads: one segmentator, multiple parsers,
 * and one reader thread -- that is, the one from which readImpl() is called.
 * They operate one after another on parts of data called "processing units".
 * One unit consists of buffer with raw data from file, filled by segmentator
 * thread. This raw data is then parsed by a parser thread to form a number of
 * Blocks. These Blocks are returned to the parent stream from readImpl().
 * After being read out, a processing unit is reused, to save on allocating
 * memory for the raw buffer. The processing units are organized into a circular
 * array to facilitate reuse and to apply backpressure on the segmentator thread
 * -- after it runs out of processing units, it has to wait for the reader to
 * read out the previous blocks.
 * The outline of what the threads do is as follows:
 * segmentator thread:
 *  1) wait for the next processing unit to become empty
 *  2) fill it with a part of input file
 *  3) start a parser thread
 *  4) repeat until eof
 * parser thread:
 *  1) parse the given raw buffer without any synchronization
 *  2) signal that the given unit is ready to read
 *  3) finish
 * readImpl():
 *  1) wait for the next processing unit to become ready to read
 *  2) take the blocks from the processing unit to return them to the caller
 *  3) signal that the processing unit is empty
 *  4) repeat until it encounters unit that is marked as "past_the_end"
 * All threads must also check for cancel/eof/exception flags.
 */
class ParallelParsingBlockInputStream : public IBlockInputStream