client/core: ensure redeem is accepted before confirm/complete match

[chappjc]

In certain cases, the redeem confirmation status was skipping the retries of the 'redeem' request. This was happening because confirmRedemption would advance the status to confirmed regardless of whether there was a stored RedeemSig, which indicates that the redeem request was accepted by the server.
This fixes the issue by adding the RedeemSig check to shouldConfirmRedemption, which allows resendPendingRequests when they are needed. only advancing to MatchConfirmed if both (a) match is confirmed, and (b) server has received and ack'd our redeem request, which is necessary to complete our role in the swap dance.

[martonp]

LGTM. shouldConfirmRedemption could return false if match.redemptionConfs > match.redemptionConfsReq, but nbd.

[chappjc]

LGTM. shouldConfirmRedemption could return false if match.redemptionConfs > match.redemptionConfsReq, but nbd.

Will you walk me through this? I might be missing a detail.

Summary of the changes in current PR:

• sendRedeemAsync sets status to MatchComplete, or if confs already checked and confs >= req, MatchConfirmed
• confirmRedemption always sets/updates match.redemptionConfs, match.redemptionConfsReq. If there's also a RedeemSig already (or the trade is self-governed), it sets to MatchConfirmed

shouldConfirmRedemption is unchanged and will say false if already MatchConfirmed, which is correct since that state is only when confs >= req, set from a previous confirmRedemption call. So it will keep updating confs until either of the above sets it to MatchConfirmed. Is this last case of extra updates past req what you meant?

[martonp]

Is this last case of extra updates past req what you meant?

Yes. I guess it's better this way though.. the UI will be kept up to date.

[JoeGruffins]

I'm not sure but I think inside of confirmRedemption if match.redemptionConfs >= match.redemptionConfsReq but we are waiting on (len(match.MetaData.Proof.Auth.RedeemSig) > 0 || t.isSelfGoverned()) a lot of the stuff in confirmRedemption can be skipped. There is no need to continue doing toWallet.Wallet.ConfirmRedemption especially.

Also, I guess setting match.Status = order.MatchConfirmed inside of sendRedeemAsync it will skip the notification on redemptionConfirmed in confirmRedemption. Does sendRedeemAsync need to set the status to confirmed or can that not just be left to confirmRedemption?

[chappjc]

I'm not sure but I think inside of confirmRedemption if match.redemptionConfs >= match.redemptionConfsReq but we are waiting on (len(match.MetaData.Proof.Auth.RedeemSig) > 0 || t.isSelfGoverned()) a lot of the stuff in confirmRedemption can be skipped. There is no need to continue doing toWallet.Wallet.ConfirmRedemption especially.

The idea was to just keep updating the confirmation count, but you and @martonp both found this notable, so will change it. I had removed a short-circuit condition from a previous iteration: https://github.com/decred/dcrdex/compare/d0530fddea72201fe2cbe1ed01155823b0de356d..c17079563ceeaf401bd6c89399dfe88cff402d83

Also, I guess setting match.Status = order.MatchConfirmed inside of sendRedeemAsync it will skip the notification on redemptionConfirmed in confirmRedemption. Does sendRedeemAsync need to set the status to confirmed or can that not just be left to confirmRedemption?

I was trying to skip having to wait for another tick, but I think it'll do it in the same tick anyway. Updating. EDIT: Nope, won't be the same tick because the meat of sendRedeemAsync is async in a goroutine. Oh well, still changing it so it notifies.

[JoeGruffins]

Thanks for answering our nits.

[chappjc]

Thanks for answering our nits.

Not nits. I repeatedly missed some important details on this one. Thanks for reviewing.

[buck54321]

Just a rebase needed.