Use error-chain for Main Error Type

[KodrAus]

Can we make tantivy's error handling better using error-chain?

error-chain gives us better backtraces thanks to backtrace, which would be great given tantivy is complex and asynchronous, but it imposes a particular open-book structure on your error type.

Currently we've got small, specialised error types in submodules that are collected into this main user-facing Error. The idea is to use error-chain for the main user-facing tantivy::Error type and keep the specialised errors as just plain std::Errors. I guess we'd chain_err those?

Does anyone have any other thoughts/recommendations/considerations on how we could hold error-chain or something else to keep tantivys error handling idiomatic and useful? Any input would be really appreciated! I've got a quick spike here that could be a good starting point for discussion.

cc: @fulmicoton @brson @BurntSushi

[fulmicoton]

One of the main concern is that understanding tantivy's Error type will not be accessible by
editor's go to definition nor will it be visible in the rust doc.

[BurntSushi]

My general opinion is that the problems that error-chain solves are important, but that it's too much magic for my blood. Two things to note about myself:

1. I have a very high tolerance for code that is annoying to write, but a low tolerance for code that is hard to read.
2. I'm probably being a bit cranky.

[fulmicoton]

I empathize with 1... Especially for a libraries. Library source code eventually tends to be more Write Once Read Many than higher level application in my experience.

[KodrAus]

In addition to this I think we could add more logging to tantivy so you can get a lot of useful debug info in verbose. There's a ticket here somewhere about slog.

If error-chain is a bit too much magic then we can use backtrace directly and tack it on to our error types like error-chain does. Reinventing it seems like a weird solution though, but would give us the flexibility to make Error a black box sometime in the future.

Alternatively if out-of-the-box logging is going to have all this detail then we could rely on that and leave the errors mostly as they are. We could have a bail! macro of our own that grabs a backtrace if configured and tacks it on to the log.

Thoughts?

[fulmicoton]

@KodrAus quick update... Let's give it one more week of thoughts.

[fulmicoton]

@KeenS corrected me. The errorkind not showing in the rustdoc was just a matter of it being publicly exposed.
I think it might be a good idea to use error-chain for tantivy's toplevel error.

[KodrAus]

Ok, I'll get the error-chain branch in a reviewable state and open a PR 👍

[KodrAus]

Closed by #177. The main Error type is now using error-chain and the directory errors implement std::error::Error.