Implement error handling

[matthiasbeyer]

This patch implements the first step to proper error handling instead of just logging errors using the log crate.

---

There's a lot to do in this crate to bring error handling and config validation up to the state of art. This is only the first step, basically "to get the foot into the door" for doing error handling the proper way here.

Let me know what you think!

[locka99]

In principle I don't mind this for the configuration stuff but I could see that ConfigError bloating out to encompass other errors I already see a bit of it with the SecurityPolicy having to emit a ConfigError. It might be better for now that it doesn't and only the Config impls use that error type, or there is a mapping from a SecurityPolicyError into a ConfigError as it crosses that boundary.

[matthiasbeyer]

So the end-goal would be to have one Error type for the whole crate and that might consist of several types, one for configuration, one for the security bits you talked about.. etc.

Pseudo code:

#[thiserror::Error]
pub enum Error {
    Config(#[from] ConfigError),
    Security(#[from] SecurityError),
}

And then let the crate only return that error type and let the user handle each error kind individually, because printing stuff to stderr is not an option in a library.

[locka99]

I think for the time being confine it to configuration errors. That would be a well defined use case where we want the the client / server to just terminate and quit if config is not right. It might be that over time it extends elsewhere but generally logging is still desirable for most situations where it is possible to see a timeline of failures if there is a recoverable failure of some kind.