When a cancellable is cancelled when we call g_cancellable_connect we used to immediately call the provided callback, while this is fine we actually had race in case the cancellable was about to be reset or in the middle of a cancellation.
In fact it could happen that when we released the mutex, another thread could reset the cancellable just before the callback is actually called and so leading to call it with g_cancellable_cancelled() == FALSE.
So to handle this, make disconnect and reset function to wait for connection emission to finish, not to break their assumptions.
This can be tested using some "brute-force" tests where multiple threads are racing to connect and disconnect while others are cancelling and resetting a cancellable, ensuring that all works as we expect.
We're coming from !2759 (diffs, comment 1483096)