Gateway client registry and api routes

[durch]

Description

Adds HTTP API to Gateway, adds client_registry field to Gateway struct. HTTP api supports registering new clients and fetching existing ones. Client struct can be considered a stub where we can put useful stuff in the future. I've copied API structure from the mix node API, hopefully it won't complicate smooshing much.

Checklist:

• added a changelog entry to CHANGELOG.md

[octol]

LGTM! I'll leave any possibly impact on smoosh to @jstuczyn

[jstuczyn]

Oh yeah. the impact on smoosh will be juicy. bunch of merge conflicts expected, especially since I opted to use axum over semi-unmaintained rocket. But that's a future me problem : )

However, to help me out here, mind making the following changes:

• remove that http_api_port from Gateway struct, @mmsinclair and I decided that the API should be accessible on the good old ports 80/443. This way, as an extra bonus, you don't have to migrate the contract
• would you mind slightly adjusting the routes? Add /api/v1/ prefix to indicate the API version and maybe also something to show it's a wireguard related route. Maybe /api/v1/gateway/client-interfaces/wireguard/register, /api/v1/gateway/client-interfaces/wireguard/clients and /api/v1/gateway/client-interfaces/wireguard/client<pub_key>.
  The reason I'm suggesting those particular routes is because I'm currently using the following scheme. Though I'm not totally convinced myself for that /gateway/ segment once the full smoosh is finished:

[durch]

Complicated things quite a bit, added MAC verification and replay protection for new registrations, I'll probably do some tidying with the structure, possibly add swagger, but I think the functionality is done now...

Also moved to axum

[durch]

Rebased off develop