I introduced this problem in change set 33 when I redefined
RejectionReason from a uint32 to an int. I have added a test
to verify the message can be marshaled correctly.
This was a bit hard to track down as the recover in clientConn
mainLoop would catch the panic and shutdown the connection. We
probably shouldn't be using panic inside marshal/unmarshal, at
least not without a way to let the user know why the recover
logic tripped.
R=agl, kardianos, gustav.paul
CC=golang-dev
https://golang.org/cl/6210063