Sweep stuck if transaction is replaced by another one

**Expected behavior**

The Sweep should continue even if the collaborative transaction is, for some reason, replaced by another one.

**Actual behavior**

When performing a Sweep, it was stuck at the first transaction for 24h. After stopping the Sweep, I noticed that the balance minus the fee is sitting in the Apricot Jar with 0 confirmations for many hours; the miner fee was high enough to go through. Sending funds to a different Jar errored with "-25 bad-txns-inputs-missingorspent". After restarting the service, the funds appeared in the Blueberry Jar with ~100 confirmations.

Here is what I was able to get from the logs. The first transaction (let's call it TX1) was successfully created, signed with all parties, and broadcast to the network. Jam removed 3 UTXO that were inputs to TX1 and created 1 UTXO from the output of TX1 that pointed to Apricot Jar. For some reason, TX1 was replaced by a different transaction TX2 that had the same inputs but different outputs. TX2 was mined, but Jam was waiting for TX1 to be mined, which would never happen because TX2 had replaced TX1. That's why the Sweep was stuck, and Apricot showed balance with 0conf. After restarting the service, Jam picked up the TX2 and the outputs that were pointing to the Blueberry Jar.

**Steps to reproduce the problem**
1. Start collaborative transaction
2. While it is not mined replace it with another one

**Specifications**
- Version: 0.4.1~1
- Platform: StartOS 0.3.5~1
- Browser: Tor 15.0.3