Add a message retransmission sub-system

[Roasbeef]

Message retransmission has now been described in detail within the spec. The implementation specified is (at a high-level ) rather straight forward: for each message sent, there exists a message which when received implicitly "ACKs" the message sent. Once the message has been ACK'd, the sending node does not need to retransmit any message to the target peer which have been ACK'd.

I have a sketch that I thin allows for a simple implementation, while logically centralizing the logic for transmissions into a single place within the daemon.

Currently when a sub-system needs to send a message directly to a peer, it uses the peer's queueMessage method directly (with some exceptions). Rather than using that method, all requests to send directly to a peer should instead be routed through the sever's sendToPeer method. This allows funnel all send requests to a single point so we can compactly include our retransmission logic.

Within sendToPeer, before sending the message, the re-transmission sub-system should first be notified of the new send attempt to it can flush the message to disk within an area dedicated to un-ACK'd messages by that peer. The storage can either be implemented within boltdb or within flat-files, with the latter likely being more performant. Within the readHandler, upon receipt of a new message, the retransmission sub-system should be notified of the new message. If the message ACK's a previously un-ACK'd message, then the entry can safely be deleted.

If the server is unable to send the message to the peer due to it being offline, them the message should be queue'd on-disk to be transmitted upon connection of the peer.

Finally, upon reconnection, when first creating the peer and after the init message is sent, then the un-ACK'd queue for that peer should be examined. If it's non-empty (or exists), then all the messages should immediately_ be retransmitted to the remote peer before accepting any other send requests.

Follow Up Tasks

A similar sub-system should be added within he daemon that ensures that all transactions broadcast eventually end up in a block. This capability can either be included within lnd itself, or the WalletController contract be extended to ensure that all transactions submitted to the PublishTransaction method are rebroadcast until confirmation.

[andrewshvv]

will take this one