After just browsing through part of this thread, it seems clear to me that this is another case of thread pool starvation, with the same underlying problem as OH Stops Properly Processing Changes, but a different bug causing it to happen.
The Exec and Chromecast bindings were “isolated” in #19133, but other binding clearly do the same mistake: Use the shared thread pool for blocking operations. The Tado binding is to blame here, from at quick look at the binding, it uses the shared pool in 5 different locations, and at least one of them (possible two, would need to study the code deeper to know for sure), it does blocking I/O using the shared pool.
This will cause most other bindings to stop responding when something “goes wrong” with the blocking calls. Normally, they will be relatively quick and it works, but as soon as something goes wrong, resulting in waiting for timeouts, or worse, deadlocks like it seems was the case with the Tado binding, it will consume the entire threadpool, and everything will grind to a halt.
So, while it seems like the deadlock has been fixed, the fundamental “error” if using the shared pool for this is still there.
https://github.com/openhab/openhab-core/pull/4948
..which is scheduled to be released with 5.1 might help to “find” the bindings that do this when things go wrong, but it won’t prevent to problem, nor will it reveal all those that do it when things don’t “go wrong”.
I don’t know to which extent this has been a problem in the past, but it seems that this problem is nothing new for 5.0, and has probably been like this for a very long time. I’d expect this to come up steadily over time, since the (ab)use of the shared thread pool seems to be very prevalent.