Thanks for this PR!
Just for my understanding: Why are there idling threads? I would have thought that the current implementation is meant to have only exactly one thread being active, doing the next scheduled flush. Through the bug that you have discovered, the cancelling and rescheduling does not work, so I assume that this is the reason for the multiple threads, isn't it?

But if this is the case, fixing the bug should be enough. Introducing a thread pool (with 10 threads) does not seem to be very useful here or am I missing something?

There was one instance per file and one timer thread per instance, on my system 20 instances are a live, backed by 20 threads. Now there is a named pool of 5 threads (as per default configuration) shared by all 20 instances.

ThreadPoolManager.getScheduledPool will allways return the same instance from the internal cache. I did not make the scheduledExecutorService field static, as other areas using the ThreadPoolManager store the pool in an not static field. So i did assume this is the code style used here.

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/looking-for-brave-testers-less-threads-for-rule-engine/157224/3