multi: define wire error types.

[dnldd]

This updates the wire error type by clearly defining package errors and updating call sites.

This is work towards #350.

[matheusd]

Just a couple of suggestions for the design of ErrorCode and MessageError. I'm not sure whether these were already considered or not so I'm just recording them here.

Feel free to ignore them if this has already been discussed and the design of the error structures explicitly decided as they were implemented.

[jrick]

How are these error codes going to be used to solve the linked issue? I'm not sure what the plan is with them or why they are necessary.

[dnldd]

Errors generated processing messages from peers can now be checked if they're bannable or not with these definitions. Take a look at IsBannable.

[davecgh]

So, now that the intent is to create more programmatically identifiable errors, I would highly recommend that the textual prefix of the function in the error messages be removed in favor a new field in the Error struct which identifies the originating message. That way it's not only possible to switch on the specific error code, but the origin message type could also be examined. I can foresee that being an important distinction as something more generic like ErrInvalidMsg might have different behavior depending on the specific type of message.

It will also significantly clean up the error messages and reduce the need to repeat the function name constantly, which is error prone and I would be willing to bet there are cases where it's not even correct anyway.

[dnldd]

I agree, adding the originating message to the error as you stated should clean up the error message, reduce the function name repetition and also provide more context. I'm going to get that done in a different PR.