Fix: make sure plugin can be stop-ed

[kares]

Currently not all specs from the suite are run, as some are tagged with redis.
These require a real Redis server, no reason not to run them against CI as well.

While getting CI to run the rest of the suite I realized the plugin isn't always interruptible.
In case of data_type => channel and data_type => pattern_channel the Redis API used is blocking (simply waits forever until more data comes in) thus the change to use an alternative "timeout" APIs with these.

[kares]

this timeout is internal for the redis (read/write) operation, we catch TimeoutError and retry in a loop,
provides a way for interrupting the input.

[yaauie]

Since we have multiple timeouts here in layers, it would be helpful to name this something distinct.

Suggested change

	TIMEOUT = 5 # Redis only supports Integer values
	BLOCKING_CALL_TIMEOUT = 5 # Redis only supports Integer values

[yaauie]

I think fundamentally, we need to allow the blocking operations on pub/sub and to find a way to kill them from the outside if they are still running when the plugin is stopped.

Otherwise, we invite the race condition where low-volume topics end up missing events because they arrive on the topic in the window between one subscription timing out and the input re-attempting to subscribe.

[yaauie]

Since we have multiple timeouts here in layers, it would be helpful to name this something distinct.

Suggested change

	TIMEOUT = 5 # Redis only supports Integer values
	BLOCKING_CALL_TIMEOUT = 5 # Redis only supports Integer values

[yaauie]

Nitpick: I would expect a method called handle_error to return true if the error had been handled, but the way that we retry here indicates the opposite.