Add error source implementation

[viraptor]

Without this it's hard to figure out in code what's the real reason for
the failure. Parsing the description is not enough.

[BratSinot]

Any progress? I need such functionality to know about websocket connection errors.

[danii]

I personally feel that the current Error type in warp is fundamentally flawed. It shouldn't store a dynamic reference to the error, it should be able to store the error inside itself and give you information from it, such as an OS error code or any data pertaining to the error. Extending the current implementation just makes it harder to switch to an implementation like that. That's just my two cents though.

[viraptor]

@danii I don't believe you can realistically wrap all possible exceptions in this case and forward their properties. They could be segregated into some groups which could give back enough details that you don't have to dig into source in a common case. But writing a mega-wrapper which can handle every case of ssl, socket, parsing, logic, etc. error and keeping it complete over time is unlikely to be realistic. (if one of the dependencies get updated and includes a new possible error case, warp apps couldn't examine that until warp is updated (and that would bump minimum required dep version to support that error))

Also, some of those underlying errors already implement .source(), so warp would have to both forward those and not implement its own .source(), which is weird.

.source() is in the standard library already - deviating from that should have a really strong reason.

[jxs]

LGMT thanks!