Use event pool for LocalMessageBroker

[ehpor]

Currently there is only a single Event that gets triggered for all message topics. Each subscription waits on this event and after it wakes up it checks if there is a new message for them. If there is not, that is, a message on another topic was submitted instead of their topic, then they go back to sleep on the event once again. This however leads to every waiting thread waking up on every message, with each thread vying for the same CPU time. This problem is known as the thundering herd problem.

We can alleviate this problem by having a single Event per topic. However, since everything needs to be created at creation time of the message broker, this means that we need to allocate 65000+ events, something that is not feasible. Instead, we create a pool of events (128 in this PR) and use the hash of the topic to index into that pool. That way, the waiting threads are separated into separate bins and are not woken up accidentally as much. Only in cases of collision are threads woken up accidentally.

TODO

• Check whether we need a hash function or if it's even better to just number the topic headers sequentially.

[ehpor]

I think using a hash for the event slot index is the better solution. It provides consistency from run to run (it doesn't depend on the order in which events are created) and it will still distribute the slots evenly. No need for the extra complexity of a sequential number.