Consider direct transfer of `MutableLogEvent` between threads 3.x

[ppkarwasz]

Currently instances of MutableLogEvent are prevented from traveling between threads. In 2.x the reason was simple: the event was bound to a ThreadLocal and was cleared upon the return from the logging statement.

In order to transfer the data between threads two mechanisms were used:

• the data was copied to another copy of MutableLogEvent (or similar) bound to a ring buffer (technique used by AsyncLogger and AsyncLoggerConfig),
• the data was copied to an immutable log event (technique used by AsyncAppender and AsyncLoggerConfig).

These mechanisms either required the pre-allocation of an amount of MutableLogEvent instances twice the number of the application threads (an instance per-thread and an instance on the ring buffer) or generated a large amount of garbage.

Proposal

Since the introduction of #1401, neither of these mechanisms is necessary: when coupled with a non-ThreadLocal (and non ScopedValue) recycler, the MutableLogEvent can be safely transferred to another thread and released on the asynchronous thread.

Possible cons

If the events are released on an asynchronous thread ThreadLocal-based recyclers can suffer from starvation: the released events will only be available on the asynchronous thread, were no logging statements are issued.