Add integration test for R errors

[lionel-]

Branched from #542

I was confused for a while trying to make tests for execution errors because of some puzzling ambiguities:

• In the Jupyter protocol all replies have nominally one type (foo_reply with foo corresponding to the request name, e.g. foo_request), but they each have two different structural types. When the status field is "error", all fields are omitted and instead the exception fields (ename, evalue, stacktrace, represented by the Rust type Exception) are included. The contents of the error variants of these messages are represented by the Rust type ErrorReply, which currently has "error" as message_type().

• As special case, the error variant of "execute_reply" messages must also preserve the execution_count field. This is represented by the Rust type ExecuteReplyException.

  Ark handles this downstream and for this reason (I think) we don't use send_error() in Amalthea's Shell socket, we use send_reply() in both cases, which is also confusing:

  ark/crates/amalthea/src/socket/shell.rs

  Line 235 in 1c7a78f

  Err(err) => req.send_reply(err, &self.socket),

• Execution errors are also signaled on IOPub with messages of type "error". These are represented by the Rust type ExecuteError.

Things changed in this PR:

• I was confused by ErrorReply having the same message_type() (

  ark/crates/amalthea/src/wire/error_reply.rs

  Line 31 in eef44b6

  String::from("error")

  ) as IOPub's ExecuteError messages (

  ark/crates/amalthea/src/wire/execute_error.rs

  Line 24 in eef44b6

  String::from("error")

  ). AFAICT this message type is never used. The payload is included as is by error_reply(), see

  ark/crates/amalthea/src/wire/jupyter_message.rs

  Line 347 in 1c7a78f

  pub fn error_reply<R: ProtocolMessage>(

  . It only needs a message_type() method for type reasons involving expected traits. So I set the message type to "*error payload*" to better reflect it's only a placeholder.

• We now take precautions in the try_from() method that deserialises Jupyter messages to disambiguate between the regular and error variants of "execute_reply".

• The error situation is now better documented so it's not as confusing the next time we have to deal with Jupyter errors.

[DavisVaughan]

I think I wish every reply was structured like this

pub enum ExecuteReply {
    Success(ExecuteReplySuccess),
    Exception(ExecuteReplyException),
}

There would be a lot of duplication, but I think it would make the structure a lot cleaner and less confusing. And ExecuteReplyException's special case of adding the execution_count would fit right in with no issues in this world - the ExecuteReplyException would just have 1 more field than most exception structs

[DavisVaughan]

It would be a bit like how we have ExecuteResponse, but "response" is a confusing name because its really a "reply" that correctly encapsulates the two variants in the way id like them all to

pub enum ExecuteResponse {
    Reply(ExecuteReply),
    ReplyException(ExecuteReplyException),
}

[lionel-]

This was my feeling too.