[IoContext] document and fix possible scenario resulting in lost wakeup

This is fixed by using a normal lock instead of the try lock in the OWNER
case.

emper/io/IoContext.cpp

@@ -322,14 +322,36 @@ reap_cqes:
 	// Number of actual continuation fibers resulting from the reaped CQEs
 	unsigned continuationsCount = 0;
 
+	// TODO: Is using a try lock and the waitInflight flag here even sound?
+	// Coudn't it be possible to have a lost wakeup with unconsumed new work notification
+	// cqe in our CQ
+	//
+	// State only a single worker does work involving IO and another (completer, io-stealing
+	// worker accesses its CQ.
+
+	// Other            Owner
+	// |                submit IO
+	// |                lock
+	// |                prepare to sleep
+	// |                set flag
+	// |                unlock
+	// |                sleep
+	// lock             |
+	// |                try lock unsucessfull
+	// |                sleep again
+	// check flag       |
+	// unlock           |
 	if constexpr (needsCqLock) {
+		// The Owner always takes the lock to reap all completions and especially
+		// new work notifications and prevent the above discribed problem.
+		if constexpr (callerEnvironment == CallerEnvironment::OWNER) {
+			cq_lock.lock();
+		} else {
 			// Someone else is currently reaping completions
 			if (unlikely(!cq_lock.try_lock())) {
 				LOGD("unsuccessful try_lock from " << callerEnvironment);
 				return 0;
 			}
-
-		if constexpr (callerEnvironment != CallerEnvironment::OWNER) {
 			// We have to check the waitInflight flag with the cq_lock held to
 			// ensure we observe an update by the worker holding the lock.
 			// Otherwise this could happen: