Improve error handling

[dbrgn]

Go over errors, handle them consistently, don't use unwrap.

Regarding the error macro, we should probably switch to https://github.com/tailhook/quick-error.

[rnestler]

Maybe we should switch to https://docs.rs/error-chain/0.10.0/error_chain/

[g5pw]

So, I'd like to try and tackle this one, maybe using failure as mentioned in #67

[dbrgn]

@g5pw great, I assigned you!

I'm a bit unsure about failure. It has a few advantages, but also a few disadvantages. But those mostly affect libraries.

Since spaceapi-server-rs is mostly used directly by the end user, I think it would be fine though. @g5pw if you want you can take a closer look at what failure offers and what advantages and disadvantages are. Maybe error-chain would also still be a good option, it would allow us to chain errors from the spaceapi-rs and spaceapi-server-rs crates.

Another option would be to just keep using quick-error, but to create a custom error enum for all types of errors that can happen in this crate.

[g5pw]

Hm, from a quick look it looked like failure crate would be the successor of error-chain, but apparently that's not the case. I'll try to look more into it in these days :)

[g5pw]

I though about this for a while and read both intros, it looks like error_chain has a simpler api than failure. I'll try porting to that and see how it goes :)

[rnestler]

Looking at it now I'd prefer to use https://crates.io/crates/thiserror since we already use it in https://github.com/spaceapi-community/spaceapi-rs

[dbrgn]

Both error_chain and failure should not be used anymore. In general I recommend thiserror for libraries and anyhow for applications.