Fixed deadlock

[Limraj]

Remedies

• [ ] The direct cause of deadlocks is an incorrect implementation of synchronization in the RuntimeManager class; reading of these structures should not be blocked, but a lock should be established when setting and changing these structures;

• [x] #2887

The additional step will be to add tests to monitor deadlock occurrences using the work-items/threads API;

Actual Behavior

1. Medium priority pool configuration in code: mediumPriorityService = new ThreadPoolExecutor(3, 100, 60L,TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>()); because the pool uses a queue without specifying its size limit, this causes the pool to never exceed 3 active threads;

2. When two threads from this pool deadlock, it leaves one active thread that can perform tasks from the queue, which essentially limits its throughput;

3. If, in addition, another thread appears in the place in the code where the deadlock occurred, it will naturally be suspended there, as a result, tasks from the queue from the medium priority pool are no longer executed at all if new tasks appear, this only increases the queue, which we observe by accumulating in the medium priority pool and it grows indefinitely;

In version 2.7, one of the causes leading to a deadlock has been eliminated, but recently I managed to achieve this state several times using a 'State change counter' detector that counts the number of changes in a given time, so I discourage the use of this type of detector for now.

Specifications Scada-LTS Version: 2.6.18

Related #1805