Key generation was performed using pyca/crpytography but keys were expected to be objects from coincurve. This comes from teos_cli where keys are generated beforehand and stored, and later on loaded from disk. The plugin generates keys and uses them straightaway (at least the first time), so it would fail in that case.
invalid_appointments in TowerInfo was used to stored invalid appointment responses from the tower when it was misbehaving (i.e. wrong or missing signature). However, a single item was stored since the tower is abandoned after misbehaving. data reported as invalid by the tower was not backed up.
invalid_appointments now stores the appointment rejected by the tower and reported as invalid.
misbehaving_proof stores the proof of misbehaviour by the tower (single item)
The previous approach was a bit messy with the db access and could have potential race conditions and data inconsistency
Also replaces format for f-functions for readability
- The appointment constructions is left in Watchtower (via on_commit_revocation method)
- The tower interaction is moved to net/http so it can be reused
- Adds missing logic for invalid resposes by the tower (e.g invalid signatures)
- Logs data identified by tower_id instead of endpoint
- Adds Retrier to deal with retries (for connection errors and rejects) and moves sending logic to net/http
- Adds pending appointments to TowerInfo and serves that information via `get_tower_info` and `list_towers`
- Deals with connection errors (but not with rejections yet)
- Moves from *args to required params after 5f33d63cb6
- tower.endpoint -> tower.netaddr
- Adds basic exception handling logic in add_appointemnt
- Stores appointment data in the database (locator: signature) and keeps summary on memory
- add_update_appointment handles the slot count and also keeps a copy of the appointment uuid and slots taken.
- gatekeeper.appointments is turned to a dict uuid:slots so appointment updates can be computed with no further data
- deleting appointment will also allow to update the slot count with no further data from both the Watcher and the Responder
The ExtendedAppointment is passed to the Watcher without user_id, since the user is not yet authenticated.
The Watcher has to add the user_id to the ExtendedAppointment after the user is authenticated.
