Connection should be passed into flowmachine query classes

[maxalbert]

Closely related to #391, the query classes should be refactored so that the flowdb connection is passed into them, rather than the connection being instantiated globally and accessed through Query.connection. This would have the advantage that we can more easily pass a dummy connection during tests, and hopefully allow creating query objects without a active connection.

[greenape]

Thinking more generally, the following things are created as persistent objects attached to Query by connect:

• db connection
• redis connection
• threadpool

And used by calling Query.thing thereafter. At present, connect returns the db connection. So I'm wondering if it should actually return all three as a named tuple or similar.

[maxalbert]

Agreed on returning all three. I still don't really see Query as the right location to store these things, though - at least not as the place where to access them again later. I wonder if instead there should be a global (singleton) object that manages all these resources and which is instantiated when connect() is called? This wouldn't obviate the need for passing connection objects and similar resources to Query (and anything else that needs them) as a dependency - rather, it would provide an object with a clear interface and set of responsibilities that can be passed as such a dependency (or alternativey, the db connection, redis connection and threadpool can be passed separately - but we should likely have dedicated classes that manage each of these).

[greenape]

Definitely don't want them stuck on Query.

You're thinking something a bit like flask's contexts and g stuff? Definitely a possibility.

[greenape]

I'm thinking about this one again (it bugs be to have not resolved it).

So at a highish level the options I see are:

1. Require db, redis and thread pool to be passed into all Query objects at instantiation
2. Require whichever of these to be passed into any method that needs them
3. Put all of them on an alternative global singleton object somewhat like the way flask handles request, app etc.

3 definitely feels easiest in terms of the refactoring, and still opens up some possibilities in terms of easier testing and using multiple connections.