situations to cover:

When connecting to a (server) thread's signal, a tunnel functor is sent from the client thread to the server thread.
Thus, the server thread's signal holds a funtor with entities from the client thread like the dispatchable (and its dispatcher) and trackables eventually.

The tunnel functor itself blocks tracking of trackables, but has a validity tracker to offer its own tracking mechanism. Note that if a tunnel functor is copied, the copy shares the same validity trackable.

If something happens to these entities (when they go out of scope) or when either the client or the server thread ends or when the last tunnel functor holding the validity tracker goes out of scope (e.g. because the server thread ends or the functor is explicitly disconnected) then these situations must be managed to have a clean connection state.


1) A trackable goes out of scope
2) The dispatchable goes out of scope
3) The dispatcher goes out scope
4) The client thread finishes
5) The server thread finishes (and the functor is disconnected)
6) functor is explicitly disconnected
