Changed RedisSubscriber wait with TaskCondition vs Timers

This update provides stability and performance improvements to the `RedisSubscriber`:

- Uses `TaskCondition` notifications rather than rearming timers throughout the class.

- Permits queuing actions in case multiple tasks are communicating, the old Timer/null check method had undefined behavior.

- Fixes an error with the `ConnectionPool`, where connections could be re-used after they were closed. An assertion on the new event driver required this fix.
To make this more robust, the original condition should be checked here instead of relying on the return value of `wait` (a good guideline to follow when using condition variables in general):
```
synchronized (m_capMutex) {
	if (m_listening) m_captured.wait(5.seconds);
	enforce (!m_listening, "Failed to wait for Redis listener to stop.");
}
```

In this case, since there is nothing that `m_capMutex` actually protects, the `synchronized` block can also just be removed. But it seems like logically there should instead be a `m_statusMutex` that protects`m_listening` and `m_capture`. This mutex would then be passed to both, `m_captured` and `m_started`. (always remember that the mutex is associated to the *data* and not to the *condition variable*)

A second mutex, `m_connMutex` may be necessary to protect the individual calls to `_request_void`, but that is a separate concern from the wait functionality.