ipc_*: In native calls, handle interruption via signal <=> EINTR. #163

This is related to #88. Suggest tackling them at the same time.

• ipc_*: The (very few) blocking APIs' behavior on signal = inconsistent, some uninterruptible. #88 is about our (few) blocking APIs, and how they should a signal happening in the middle. In short: it probably depends on the API (e.g., the Posix_mq_handle::timed_() guys are low-level and should -- and I believe do -- just emit an EINTR-wrapping code; rest of Flow-IPC does not use these timed_*() guys; they're provided to users as a nicety if they want to do this low-level stuff directly); thoughts are in the ticket. That said that was written a while ago; new info around the present ticket might be a helpful cognitive addition.
  • Quick side note of that nature: Bipc_mq_handle::timed_() invoke Boost stuff, and Boost has apparently improved EINTR-discipline widely in Boost-1.87 which IIRC released after ipc_*: The (very few) blocking APIs' behavior on signal = inconsistent, some uninterruptible. #88 was filed.
• Cf: The present ticket is about the situation where:

we call a native thing, especially things that one naively might assume are non-blocking and do not EINTR, and that thing emits EINTR: what do we do? Should we retry (probably, if it's a naively non-blocking call particularly)?

I'll leave the full investigating until the actual fix attempt.

Random notes

That said I do want to point out that, specifically, the recently-added Sparse_shm stuff in shm::bipc_ext, which extends some central bipc.shm classes (shared_memory_object, basic_managed_shared_memory) invoke things natively, as bipc.shm does, and those things "feel" like they won't EINTR, but they can in some cases.

• ::fallocate() (in Sparse_* commit()) can actually EINTR. It goes through potentially many pages, and for huge pool-sizes that can take seconds. What to do? Pretty good question actually. Retry seems right; if we are not OK with commit() taking seconds (I think we pretty have to be), then that is orthogonal to EINTR handling. If we don't like that, then we'd need to add other code to somehow stop in media res, if it's taking too long. (Let'sn't, I think.) / Correction: we already do it (retry).
• ::shm_open() (sorry... not in SHM-classic/Sparse_*... but SHM-jemalloc code does it, as its author preferred not to go through bipc.shm): man in Linux does not list EINTR that I can see; POSIX allows it allegedly though. Possibly handle it just in case.
• ftruncate(): man in Linux lists EINTR. This might not be actually possible. Possibly handle it just in case, as I believe Boost-1.87+ does. / Correction: we already do it.

So apparently nothing to do in Sparse_* land, but the SHM-jemalloc note does somewhat apply. Anyway! The full investigating => later.