Problem:
 * In certain scenarios TempTable custom memory allocator will have a
   very hard to spot but a bit confusing allocation patterns wrt the
   block-size of given growth policy (default growth policy is
   exponential).
 * Consequences of this behavior may result in increased memory
   consumption but there is no loss in terms of functionality or
   performance.

Analysis:
 * Given that there are at least two allocator instances in the system
   which are sharing the same shared-block state, allocation patterns
   (actual block sizes) with exponential growth policy are expected to
   grow with { 1MB, 2MB, 4MB, 8MB, ... } pattern.
 * It turns out that, because of the shared-block state, this pattern
   may look differently.
 * For example, first allocator instance will lazily allocate { 1MB }
   shared-block after which it will continue with allocations following
   the { 2MB, 4MB, 8MB, ... } pattern, whereas second allocator instance
   will follow the { 1MB, 2MB, 4MB, 8MB, ... } pattern.
 * The difference is in the first _non_-shared-block size: first instance
   picks 2MB and second instance picks 1MB. Expected behavior would be
   that the first allocator instance picks 1MB as well.

Solution:
 * Mechanism which decides what will be the size of next block to be
   allocated needs to be tweaked in a way so it doesn't account for
   shared-blocks as this is where this discrepancy stems from.
 * E.g. memory allocator shall not be modifying its internal state to 
   increase number of blocks which have been allocated so far in cases
   when it is operating with a shared-block.

Reviewed-by: Mateusz Rukowicz <mateusz.rukowicz@oracle.com>
RB: 25249