Caller-controlled server panic when overly long messages get truncat #37
Description
Currently, the runtime code slices the server-side buffer using the kernel-provided message length, under the assumption that the kernel won't lie to us. https://github.com/oxidecomputer/idolatry/blob/main/runtime/src/lib.rs#L228
However, this misses a subtlety of the Hubris RECV primitive as currently defined: if a client sends a message too long for the server to receive, it's delivered to the server with the original length. It's the server's responsibility to notice this and do whatever's needed to handle the situation.
I think an argument could be made that this behavior is bad, but, that's another bug report.
Anyhoo, Idol servers need to check this situation before slicing the receive buffer and handle the situation somehow (likely via reply-fault).