Listener causes easily race conditions

Required information

When using the listener it starts a background thread and operates on the attached objects concurrently whenever the specified event occurs. This causes often the same bug when it is being used - race conditions since the background thread is well hidden from the user and they are not aware that they may operate on the object concurrently. And most objects are not thread safe.

To fix this API bug causing issue I would propose an API change on the listener so that the listener takes the ownership of an object when it is being attached and release it when it is detached.

// returns some kind of handle to the attached event
cxx::expected<Handle, ListenerError> attachEvent(T&& eventOrigin, // <- takes the ownership of the attached object
                                             const EventType eventType,
                                             const NotificationCallback<T, ContextDataType>& eventCallback) noexcept;

// returns the ownership of the attached object
T&& detachEvent(Handle eventHandle, const EventType eventType) noexcept;

This would solve the problem and cause another problem. Then the listener must provide enough memory so that arbitrary objects can be attached to it and this makes it to a memory hungry monster.

Does anyone has some inspirational idea how we can fix the memory part? @elBoberido @MatthiasKillat @FerdinandSpitzschnueffler

Start at the listener API and the proposed attachEvent/detachEvent entry points. Trace how the background thread accesses attached objects and how attachment and detachment currently manage lifetimes. Done means an agreed API and memory strategy that prevents concurrent access to non-thread-safe objects without making the listener impractical.