mgnp: better error handling

[hawkw]

right now (as of 87dc51d) we handle frame decode/encode errors by "just skipping the frame", and wire errors by "just stop running the interface". here's what we should do instead, IMO:

• on outbound frame serialize errors, do: send an error back to the local conn that sent that frame
• on inbound frame decode errors, do:
  • if we were able to decode the header and get a link ID, then: close the connection for that link ID (send a RESET to the remote/an error to the local channel, or a NAK if it was a connection being established?) and remove it from the conn table
  • else if we weren't able to decode the header and get a link ID, then: either destroy the whole interface and reset all conns, or...log an error and ignore it? idk @jamesmunns what do you think?
• on outbound frame wire send errors, do:
  • if it was a DATA or CONNECT frame, then: send an error back to the local conn?
  • if it was an ACK, NAKor RESET then: we're probably fucked, blow up the whole link?
  • if we were trying to send a RESET due to a previous error, then: hahaha we're Super Fucked, destroy everything as violently as possible
• on inbound frame wire recv errors, do: idk, either ignore it or destroy the whole world probably? @jamesmunns what do you think?

imo if the Wire sees an error that it's capable of retrying or believes to be ignorable, it should just ... do that? and the only errors that should bubble up from the Wire are fatal-ish and should blow up the whole interface.

currently, wire errors just make us stop the interface state machine. they should actually send errors on all existing local connections.

[hawkw]

some notes about the design given here:

• because decode errors result in RESET/NAKing a whole connection, rather than NAKing frames (which MGNP has no concept of), we don't need frame sequence numbers so that individual frames can be NAKed
• since we don't retransmit bad frames, no buffering/queueing is required
• alternatively, we may want to consider a design where, if we get a bad frame with a good ID, we just tell the local side of the connection "hey the remote gave you something bad", and let the service decide if it wants to blow up that connection?

[hawkw]

i think the best way to propagate connection RESETs is to stick a first-class notion of "channel closed with error" into tricky-pipe.

also, it would be nice if an attempt to send a message through a DeserSender that results in a deserialize error also sent the deserialize error to the receiver, as well as returning it to the sender...