Avoid blocked event bus

[pfeuffer]

Proposed changes

The old synchronization of asynchronous non-concurrent event handlers could lead to a blocked event bus with a single long-running event handler. For this to happen, the following situation had to occur:

1. A event had to be thrown and a (asynchronous non-concurrent) handler has to take some time to process this event
2. During this processing more events have to be thrown that have to be handled by this blocked event handler.

In this case, the handling of the following events are blocked by the synchronization in the SynchronizedEventHandler class until the first event has been processed completely. Because the synchonization happens in the handleEvent method inside the handler, this blocks a thread of the executor per event, until all threads are blocked an therefore no more asynchronous events whatsoever can be processed any more.

To avoid such situations, the synchronization is now done outside of the executor and its threads. To do so, the new class ExecutorSerializer is introduced. This class can be seen as a steward, that blocks events for event handlers, whenever a event handler of the same type is already queued in the executor to process another event. The waiting event is put in a queue outside the executor an will be taken into account again, whenever the first process has finished.

Your checklist for this pull request

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

Contributor:

• PR is well described and the description can be used as a commit message on squash
• Related issues linked to PR if existing and labels set
• New code is covered with unit tests

Reviewer:

• The clean code principles are respected (CleanCode)
• All new code/logic is implemented on the right spot / "Should this be done here?"
• UI changes fits into the layout
• The UI views / components are responsive (mobile views)
• Correct translations are available

Checklist for branch merge request (not required for forks)

• Branch is green/blue on Jenkins
• Quality Gate passed on SonarQube