This is a direct port from http.c, including _reck_lily, which should
probably get factored out.
We parse sequence numbers even though they aren't yet stored on the C
side, just in case we wind up needing them later.
Still not actually handling effects.
The vane is of course bailing all over the place, and we probably need
to handle errors better (and maybe also count task numbers / introduce
the concept of a 'request' at C level?), but we're moving...
Goes ahead and makes the socket its own separate data structure linked
from u3_khan. Makes it easier to get proper links to everything without
fiddling with offsetof. Seems to resolve the memory corruption issues we
were seeing.
Also make an effort to shutdown / close resources on exit.
Using offsetof is very gross and probably suggests something is wrong
somewhere. Maybe we should store the server configuration on a separate
object from the khan configuration? But in the case of khan there isn't
really a concept of multiple servers...
N.B. We still have memory corruption.
Implements the connection callback, which accepts and opens up the read
end of the pipe, then just waits. Stores open connections on u3_khan.
Uses simple incrementing connection numbers.
I noticed in here that vere/newt.c seems to implement a protocol much
like the one we're looking for; may try to switch to using that more
explicitly.
Needs more well-thought-out error handling policy in connection
callback. What do we do -- bail? Deliver a non-fatal error and drop the
connection?
If we received a graph-node with that was signed by a past or future
life of a ship, then we would potentially crash scrying for the public
keys. Now, if there is a mismatch between lives, we simply no-op and
treat the signature as valid.
