Installing custom signal handlers for SIGSEGV and SIGILL breaks Libdsm

[Micrified]

ISSUE: Libdsm relies on custom signal handlers for its synchronization functionality. When custom signal handlers are installed, this functionality is overridden and Libdsm ceases to function correctly.

PROPOSED SOLUTION: To fix this problem, Libdsm must provide custom handler installation wrappers. Within these wrappers, the user function will be saved and invoked in the event of a true SIGSEGV or SIGILL. The installation of Handlers will also have to involve saving existing handlers and invoking them in a chain in order to preserve user functionality installed prior.

[Micrified]

I have chosen not to invoke user handlers within those of libdsm. The reason being I simply cannot trust that they won't jeopardize the synchronization mechanisms. Instead, I save all signal handlers installed by the user before I attach those of libdsm. Those signal handlers are then restored once the session is over. This preserved the state of the user program between session invocations.

Note: I have also removed code allowing processes to ignore SIGTSTP while waiting for a write-ack from the server (via the arbiter). This was formerly needed when all processes could receive arbitrary SIGTSTP signals (in case of a write occurring elsewhere needing the system to freeze). It was ignored so that the process wouldn't deadlock when frozen within a critical section. Because arbitrary orders to stop are no longer part of the synchronization mechanism (it's a causal consistency scheme, not the hybrid), ignoring SIGTSTP isn't needed and seems to be unnecessary overhead.

[Micrified]

I will leave this issue open, because overwriting the signal-handlers is still something that will break the system if done after initialization. And it ought to be visible to visitors.