Implement a pool of reusable JsonGenerator

[brenuart]

Implement a pool of reusable JsonGenerator similar to the ReusableByteBufferPool.
CompositeJsonFormatter now acts as a factory creating JsonFormatter instances bound to an OutputStream. The output stream is backed by a ReusableByteBuffer.
CompositeJsonEncoder/CompositeJsonLayout acquire a reusable JsonFormatter from the pool, write the event to it then flush the underlying buffer into a byte array, a string or an another output stream if it implements StreamingEncoder.
This approach reuses the JsonGenerator and the associated memory buffers. It also reduces the number of memory copy operations required to move data to destination.

fixes #630

[brenuart]

Here are some benchmarks against 6.6 (test executed with -Xmx64m to reduce available memory, single threaded, openjdk-11):

                       6.6         7.0    Units
--------------------------------------------------------------------------
throughput      1.9320.000    3.713.000   ops/s    (+90%, nearly twice faster)
gc.count             1.739          230   counts   (-87%, 7.5 times less)
gc.time                644           90   ms       (-86%, 7.5 times less)

[philsttr]

Can ReusableByteBufferPool be deleted? (It looks like this review removes the only references to it, unless I missed something).

[brenuart]

Can ReusableByteBufferPool be deleted? (It looks like this review removes the only references to it, unless I missed something).

Correct. It is not used anymore. Can be removed unless I find other places where it could be useful ;-)

For the background, you may have noticed that ReusableByteBufferPool uses a Deque of SoftReference whereas the ResuableJsonFormatterPool uses a SoftReference holding a Deque (the opposite). I changed the strategy because I noticed that when the GC decides to free the SoftReference it does it for nearly all of them in the same round. It is therefore more efficient to free the Deque instead of individual elements. At least I don't have to re-create a new SoftReference every time elements are added back to the pool... less garbage ;-)

[brenuart]

About disposing JsonGenerator when a pooled JsonFormatter is GC... I had a look and the only consequence of not calling JsonGenerator#close() is that the internal memory buffers are not returned to Jackson's internal pool. As mentioned earlier this is not causing memory leak since Jackson does not seem to maintain any other reference to these allocated resources.

In fact, not closing the JsonGenerator is even better: memory is not returned to Jackson pools and is immediately reclaimed by the GC... which is exactly what we want. ReusableJsonFormatter are disposed by the GC when running low in memory - in this case it is better if the memory allocated by the JsonGenerator is freed as well.

[brenuart]

@philsttr I'm done with this PR. Everything looks good to me... Any additional comments?

[philsttr]

Just had a few more minor comments. Looks good otherwise!