Currently we hardly ever lock in the interceptor.

E.g. fb_write_buf locks so that partial writes of multiple threads cannot interleave the messages sent to the supervisor.

In all the methods that wait for an ack, the send + wait for ack steps needs to be locked. Otherwise a thread might receive another thread's ack, and bail out on the mismatched ack id.

In many of the methods, e.g. file operations, the actual ic_orig_<func>() operation also needs to be mutexed. Otherwise events occurring in different threads might arrive at the supervisor in reversed order. E.g. thread1 closes fd 4, then thread2 opens something to fd 4. If it's not properly locked, the supervisor might receive the "open to fd 4" first and alert about a missed close, and then in the next step think that this newly opened file gets closed.

The simple approach is to extend the one global lock to these ic_orig_<func>() calls. A more fine-grained version is to have other locks, one per kind of event (e.g. one for operations that potentially affect file descriptors, one for operations that potentially affecct the file system layout [I just randomly made it up, we might not need this], etc...).