Worker Architecture: Solving Problems with Deadlocks and related Locking/Mutex Quirks

It might happen that Workers with the same payload are instantiated twice since the Locking/Mutex logic gives a very short "window of opportunity" to do so when the worker is set to running.

Also the indizes of the worker table are not optimal, since to much fields are indexed and a compound index for some requests using multiple fields is missing.

The isolation level "read committed" was not used for all update / delete statements in worker context. According to https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html this level reduces the risk of deadlocks regarding updates and deletes.

For more details see TRANSLATE-2498