WIP: ingres: webhook: use hyper instead of the ad-hoc http implementa…

…tion

In the future we will likely want to do more things via HTTP,
namely serving prometheus metrics, providing a status page or
allowing the jobs inside of the machines to upload artifacts.

Growing a custom web server to do all of these things would be
possible, but not really a reasonable thing to do.

Instead use the hyper crate as a HTTP server implementation for the
webhook endpoint.

Using hyper as a server crate has the benefit of already being in our
dependencies via the octocrab crate.

As far as I can tell this is however the only benefit of hyper
(in our low-traffic usecase at least).
The interface seems to be designed by a committee of drunk lawyers that
are payed by the number of crates they split their completely bonkers
traits into, as a result of this it is about as ergononic as a designer
chair.

The documentation is strewn all over the place between all these crates
and the hyper doc writers have, in all their wisdom,
included `#[doc(hidden)]`s in their documentation, making it even less
navigable. Maybe what's hidden is proprietary knowledge that they can
bill extra for.

I hated any minute working with hyper so far.
We are in for a good time.

Cargo.toml

@@ -13,6 +13,7 @@ chrono = "0.4"
 fatfs = "0.3"
 hex = "0.4"
 hmac = "0.12"
+http-body-util = "0.1"
 jsonwebtoken = "9.3"
 log = "0.4"
 octocrab = "0.39"
@@ -25,6 +26,14 @@ serde_json = "1.0"
 serde_yml = "0.0.12"
 sha2 = "0.10"
 
+[dependencies.hyper]
+version = "1.4"
+features = ["http1", "server"]
+
+[dependencies.hyper-util]
+version = "0.1"
+features = ["tokio"]
+
 [dependencies.tokio]
 version = "1.38"
 features = ["io-util", "process", "rt", "macros"]