Refactor `add_appointment` logic to be atomic

[mariocynicys]

trafficstars

Some parts of add_appointment (the public method which users add appointments to the tower through) are not atomic:

• We update the in-DB slots AND THEN add the actual appointment in the DB, this is clearly not atomic and failure in between two db calls would deprive a user of their slots without watching their appointment.
• We check if we have a tracker with the UUID of the newly added appointment AND THEN actually add/update the appointment if it's not triggered. We might face a case where the first check (if tracker with UUID exists) returns false and we proceed with storing the appointment but find it already stored and panic. Something like this might happen if the user crafted two identical requests (same appointment) and timed them to be really close that they both pass the tracker non-existence check and both try to store the appointment.