Not pass appointment replicas to the Responder

[sr-gi]

We're currently using server-side generated uuid to identify the appointments both in the Watcher and in the Responder.

Regarding the Watcher, this comes from the fact that the locator is specified by the user, and using it as an id may result in some nasty replace attacks.

Regarding the Responder, we're passing the information from the Watcher, so we're using the same identifiers. However, the current approach to pass information to the Responder is far form efficient (it was actually better in one of the earlier approaches). Since once the appointment data is decrypted we know every bit of necessary information, passing appointment replicas to the Responder should be avoided. This would mean that, while flooding the Watcher may be relatively easy, doing so for the Responder (where the workload is heavier) shouldn't.

In a previous approach for the Responder we use to only pass one copy of the appointment from the Watcher, however, the copy we pass was the first to be decrypted. This approach is OK under certain assumptions:

• The Responder trackers are identified by penalty_txid
• The only relevant information for the Responder is the dispute_tx and penalty_tx

However, this is not true in the current approach, since the end_time and to_self_delay matter. Therefore, since a given appointment (and all it's possible replicas) can only be triggered once, a way of doing this could be to pass a single instance to the Responder with:

• locator
• dispute_txid
• penalty_rawtx
• min(appointment_end) provided it is above the accepted min.
• min(to_self_delay) provided it is above the accepted min.

This would reduce the Responder's requirements (memory and cpu), the interactions with bitcoind, as well as the storage requirements in the db. It would also make the design on the Responder way simpler.

This issue is related to #34