Custom ThreadPoolExecutor

[kevlahnota]

ThreadPoolExecutor configuration - short-lived tasks for AI Timeout. Reusable and It doesn't need to shutdown manually. Threads will die on idle. Really Bad for sequential operations where every single task must finish without being dropped. So don't use it for those. Optimize a bit for declare attackers by using a reusable runnable object and comparator so heap is reduced.

[tool4ever]

Well, not sure if you already wanted feedback but since I may not have more time later:

1. did you measure the lambda stuff? I once did some research in that direction and in general JVM should be able to cache and reuse them. Though there may be some limits to such detection logic which we're reaching here?
2. your global(!) ThreadPool creates an artificial bottleneck for other AI + other games running at the same time risk their AI becoming "braindead" for no reason while the pool is saturated with non-idle Threads
3. I see no attempt of clearing interrupted status afterwards. Since you're also allowing worker threads to get reused during some period this can lead to even more nondeterministic behaviour
4. grace wait time + stop() dropped without explanation - the final safeguard to prevent more crashes...
5. class field Thread CANCELLED_MARKER = new Thread() for every attacker? now the operating system has to spawn even more than before :/
6. please don't reintroduce old bugs, see 2676235

[kevlahnota]

@tool4ever I was getting thread death when I use Thread.stop to forcefully killing the thread. Though it may benefit desktop using java 17, It doesn't mean it will benefit on android, Also this is still WIP since Im testing on older android with limited RAM for the heap you can't increase in anyway. The marker is just marker so you interrupt the correct thread. Im avoiding the hashmap reference as it can grow up and will introduce more heap allocation on mobile platform.