fix: Use custom thread factor class in SolverManager

[Christopher-Chianelli]

No description provided.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[triceo]

Why is this being done? Do we have a request somewhere, a justification?
This is highly unusual.

[triceo]

If this is something for the Python solver, I'd prefer if we had a code branch specifically for the Python solver, and leave the original behavior of the Java solver unchanged.

[Christopher-Chianelli]

Two reasons:

• It a genuine bug: threadFactoryClass on SolverManagerConfig literally did nothing before when used on SolverManager
• Due to how Python/JVM interacts, Python Solver requires daemon threads to terminate when used with Control-C/interrupts.

[Christopher-Chianelli]

(If thread factory unset in the SolverManagerConfig, original behaviour is unchanged; Executors.newFixedThreadPool(parallelSolverCount, Executors.defaultThreadFactory()) == Executors.newFixedThreadPool(parallelSolverCount)

[zepfred]

@triceo, this change does not affect the default behavior, which already sets the thread factory to Executors.defaultThreadFactory() when calling Executors.newFixedThreadPool(parallelSolverCount);.