In the long term, we don't want to pretend we got "no result", and
handle crashes by whatever behavior is appropriate.
In the short term, we don't want to burden callsites with crash
handling, so we punt on the problem by producing ~.
Now we free the struct _and its nouns_ in the same place, rather than
transferring the nouns into lord.c, but still freeing the struct
locally.
This means the lord needs to explicitly retain the nouns in the u3_pico.
Previously, we decremented len_w eagerly, regardless of whether
u3_auto_next succeeded in getting a next event or not.
Now, we only decrement len_w if we actually managed to get a next event,
resulting in better behavior in the "no next" case.
Also lightly touches up style a couple lines down, for consistency.
Scries were being prioritized over events, in the IPC queue. If scry
requests came in faster than we could process them (as is easily the
case for ames forward requests), this would cause scries to completely
clog the IPC queue, preventing any events from being processed at all.
The short-term solution implemented here is to simply alternate between
scry requests and events when building/sending a work batch.
To accomplish this, we separate scry requests into their own queue. We
keep this in pier.c, and pass them on to lord.c interleaved with regular
events in _pier_work_send.
The interleaving of regular events (as opposed to doing scries with the
highest priority) complicates the situation around auto-filled scry
cases (for scrying at "the latest timestamp").
To ensure we're always scrying at a sane latest timestamp, we keep a
queue of u3_pico, instead of fully-qualified scry requests. Where
necessary, lord.c fills in the missing path elements right before
sending it over the pipe.
There was a TODO in runShips about how the different layers of the
RIO environment had to be changed, so that there was a layer between
KingEnv and PierEnv for things shared between individual Piers, but
which weren't used outside of any PierEnv. This addresses those
TODOs by creating RunningEnv, which for now just owns MultiEyreApi
and makes it so we don't have to pass the entire thing around
explicitly.
The IP handling stuff will go in RunningEnv in a following patch.
