Don't use honest_makers in case: mempool conflict

[AdamISZ]

Prior to this commit, if a tumbler coinjoin negotiation
failed in Phase 2, then the retry as per the logic in
taker_utils.tumbler_taker_finished_update would always
attempt to retry the transaction with those counterparties
that returned valid !sig responses. However this ignored
the case that all the counterparties responded validly,
but there was a mempool conflict in the created transaction.
After this commit, if it is detected that all counterparties
responded, it is assumed that a mempool conflict or similar
occurred with the transaction, and therefore it is better
to fallback to a schedule tweak and choose randomly again,
not to fix the counterparty set (which is likely to result
in failing again).

[chris-belcher]

Even though there's a lot of lines changed, actually most of the code has been intended and put inside an else: block. The new code is just two lines checking whether the nonrespondents list is empty. So utACK.

[AdamISZ]

Yes. I have done some tests with it, and the logic change is very simple.

[AdamISZ]

It is actually a rather needed change, as any txn-mempool-conflict errors in multi-join schedule results in just repeated failures, using up commitments.
What I actually spent a lot of time doing was trying to understand what exactly might cause this kind of scenario, even with default JM code. I actually didn't fully succeed, except clearly it can happen if people spend out of a pre-0.6.0 JM wallet while the yg is running (while after #359 that wallet change is seen and so conflicts won't happen). So this is my best hypothesis.

Meanwhile we obviously can't trust makers to do anything in particular, so this change is needed in any case.

[AdamISZ]

There also seems no point waiting further on this. I have tested it as per above and as noted by @chris-belcher , the change is very simple (not to mention, this could fix a material degradation in user experience, depending on market conditions). Merging.