Move away from CliRunner in unit tests

[remyroy]

The CliRunner from Click does not support concurrency which we are going to be using. We should find a better way and move away from using it.

[valefar-on-discord]

"This only works in single-threaded systems without any concurrency as it changes the global interpreter state."
From documentation

[remyroy]

Related to #30

[remyroy]

subprocess or asyncio subprocess are likely to way to go here.

[yorickdowne]

I suggest we do not use threading. We are CPU-bound, and because of the GIL, threading does not gain us speed: It would if we were IO-bound. See also https://realpython.com/python-gil/

Instead, use multiprocessing. With multiprocessing, every process has its own GIL. That would mean the CLIRunner would continue working, is that right? We'd be single-threaded inside every process.

GIL-less Python has started in 3.13. https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython It'll be years and years before we can rely on it being the default installation on our target systems and we could consider threading - but tbh multiprocessing will be good enough for our use case, I predict.

I see the value in writing all new tests in [asyncio-]subprocess. Maybe. I note Valefar just wrote a CLIRunner test for partial deposits 😅 .

Existing tests could be a Fleissarbeit, but I don't think it's necessary.

[remyroy]

CliRunner seems to be working good still even if we are using multiprocessing internally with the concurrent.futures.ProcessPoolExecutor. We might not need to move away from it. This would need more exploration.