Moving away from the global context #1841

Hello!

Your comment in #1839 triggered a huge reflection in my brain regarding the architecture of threads in the main package. I suddenly realized that they have the same birth injury as a bitmessageqt app: global context. I started a branch incapsulation where I'm going to address the issue in the singeWorker as an example. You cannot just take the current code and write a test case which start the singeWorker thread isolated from the rest ones, because it uses SQL, Inventory, queues and the shared objects...

In this ticket I'm going to describe the solutions I already found and formulated as they arrive, so we could continue the discussion, started in #1828.

The points so far:

• if the thread has it's own queue, where it takes commands, init it with the queue
• the same is applicable to other objects such as Inventory, BMConfigParser, etc.
• worker has nothing to do with invQueue, Inventory can feed it itself
• I'm prematurely introducing a new entity, MsgBox, the base class for Inbox, Outbox, etc. The worker needs it's method ~ get_by_status() for the queries like this. The implementation is not have to be tied to the SQLThread.
• once all the objects passed directly to their consumers, get rid of the Singleton anti-pattern.

The minor issues can be addressed there:

• use something like getattr(self, 'handle_{}'.format(command)) instead of the if: else: ladder
• try handle the exceptions where they were rised, reducing the duplicates
• move all assembly code into the protocol or it's imported submodule (e.g. fe691a5) and cover by tests

the latter will help removing all the pylint comments. You will also see why I hate those tiny formatting changes: I see most of those blocks removed or moved into another modules (e.g. cf8c3ac) but writing code takes time ):