Better design for host-originating signals

[CvvT]

I am quite surprised by this provider. There are some surprising inversions happening here, for example, it depends on crate::shim in its signature.

I don't think the Signal sits well in shim, since the shim module is meant for traits that the shim must implement but there isn't a trait being implemented there.

Also, "shim should call" implies that a shim that does not call stuff is incorrect. This sort of requirement is exactly what traits are for, and thus the way the design should be is to actually have the shim implement a trait that probably looks like the following:

pub trait ConsumeSignal {
  fn consume_signal(Signal);
}

Then the platform can always invoke this trait, and the shim can make a decision of it wants to buffer things or not. If you need/want the "all in a group" behavior, then you can make the trait (instead of the above):

pub trait ConsumeSignal {
  fn consume_signals(&[Signal]);
}

Originally posted by @jaybosamiya-ms in #690 (comment)

[CvvT]

See more discussion at #690 (comment)

The challenge is that signal handler cannot call shim directly. For example, interruption in Linux userland works as follows:
1. send interrupt signal to a thread
2. set the flag interrupt to true (signal handler runs on signal stack and does not have access to shim which is stored on a different stack)
3. if the thread is running in guest, update its RIP to execute interrupt_callback which in turn can call shim.
4. if the thread is running in LiteBox, do nothing. After the thread finishes handling the syscall, it checks interrupt before switching to guest and calls into shim.

For signals, we do want to interrupt a thread running in LiteBox, e.g.,

pub fn wait_until(&self, mut ready: impl FnMut() -> bool) -> Result<(), WaitError> {
        assert_eq!(
            self.waker.0.state_for_assert(),
            ThreadState::RUNNING_IN_HOST
        );
        let _end_wait = crate::utils::defer(|| self.end_wait());
        loop {
            self.start_wait();
            if ready() {
                break Ok(());
            }
            self.commit_wait()?;
        }
    }

In this case, to break the loop, we need to call platform to consume any signals, not the other direction. We either add a new interface (e.g., take_pending_signals) or modify the existing one RawMutex::block_or_timeout (which is called inside commit_wait). The former one is cleaner.