client added client list before finishing lss initialization

[irriden]

If the signer crashes during the reconnect dance, broker gets stuck trying to finish the reconnect dance with that specific client ID, and the signer now under a different client ID never goes through the reconnect dance, as described in #96.

Nonetheless, the client is added to the client list. Hence when broker iterates through the full list of clients attempting to send a vls message and get a good response, it sends one to the signer even though the signer is expecting an LSS message.

Signer then complains as follows, as broker keeps looping over an iteration of the full client list, sending a vls message to each one of them.

 W (37179) sphinx_key::core::lss: failed server_pubkey_from_event not an LSS msg
 W (70509) sphinx_key::core::lss: failed server_pubkey_from_event not an LSS msg
 W (73219) sphinx_key::core::lss: failed server_pubkey_from_event not an LSS msg
 W (109269) sphinx_key::core::lss: failed server_pubkey_from_event not an LSS msg

[Evanfeenstra]

• yes, the oneshot makes sense. the client_id is only added to the list after successful sync
• lets add a "retries" optional param to pub_and_wait, so for LSS init you can retry a couple times, then fail
• in LSS reconnect_dance, drop the loops. Check if the channel reply is empty, and fail if so
• move the conns_.lock().unwrap(); etc code inside the else (if there is no unspecified client id)

Its up to the signer to know if LSS init failed, and restart if so