HTTP signatures rewrite

[aumetra]

Rewrite of the HTTP signatures implementation using a more sophisticated parsing method and implementing hardened rules to hopefully get rid of any security issues that could arise from improperly implemented HTTP signatures.

Closes #195

[aumetra]

Design

This crate will expose two different API levels. A mid-level API and a high-level API.

Mid-level API

This API provides header parsing, signing string construction and verification/signing, etc. but all in separate steps.

Mostly geared towards either:

1. People who only need a part of the entire validation/signing pipeline
2. People who can't use use high-level API since they have lifetime issues, aren't using async, etc.

High-level API

The high-level API will expose a conservative set of configuration options and will have an API akin to this:

async fn (req, opts) -> bool

where the boolean implies whether the verification succeeded or failed (for whatever reason).
It exposes no metadata, no failure reasons, etc. in order to keep any crypto failures due to leakage of metadata from happening.

It's an async method and will execute the actual validation on a rayon background task. Key fetching is only done when required using a closure which returns a fallible future.
That way it will integrate neatly with all kinds of asynchronous operations you'd do on a webserver to fetch a key (be it a database operation via sqlx or diesel-async or an HTTP request).

If this doesn't fit your use-case, you have to drop down to the mid-level API, as explained above.

[aumetra]

Okay, fixed the broken clock skew adjustment. Now it should be fine. Adding one minute to every timestamp so we operate a little bit in the future.

[aumetra]

Does that look good @perillamint ?

[perillamint]

LGTM!