Introduce custom error types #7

Explain your use case

All the errors from SDK now returns in raw format.
Moreover - they are bubbling up from the very bottom level to the client level.

Describe the problem you’re trying to solve

This errors might be everything - starting from the HTTP errors (can't connect to the server, wrong credentials, smth else) to JSON umarshaling problems.

Does the client really need such verbose level of errors and does he (she) really need to know that we've got some problem during JSON unmarshaling?

Do you have a proposed solution?

• Catch errors before returning to clients
• Introduce some types of errors (internal error, server error, auth error ...)(
• Introduce some interfaces that would help to separate errors by behavior (fatal, retryable, limit exceed) - here is a good article about it https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully