processAudit runs txn search async, redo match res. locking

[chappjc]

This prevents contract auditing from blocking all incoming messages (and pretty much any other activities for the trade in question).

Instead of expiring the coin waiter after broadcast timeout, it just goes until it finds the contract or the match is revoked.

The trackedTrade locking is also changed a great deal in match status resolution, no longer locking a trackedTrade unless and until needed.

[chappjc]

Still considering if it should still try at least a couple times even if it is revoked, or is being revoked a good indicator that the audit is now irrelevant...

[chappjc]

Audit is only useful for the normal swap negotiation path, so I've concluded no, the audit is not needed for a revoked match, which will go to refund. However, I believe there is an opportunity for an improvement that would require more work: #829

[chappjc]

Working as intended, although I'm uncertain about the audit timeout during resolution.

[chappjc]

Now making sure match status and proof data updates happen before firing off the resolution goroutine.

[buck54321]

Tests well.

I do feel like there is some new added complexity around lock handling in status.go that could have been avoided. For example, the new (exported?) getter methods in trackedTrade are only needed because we're not locking for all of resolveConflictWithServerData anymore. But there were only two paths (I think) that had the potential for long delays from mutex locking, and you've already stated that the correct solution is to run auditContract in a goroutine and unlock. New pattern seems racier.

[chappjc]

I also snuck in a notification with the last commit yesterday. It's not pretty because the IDs are too long, but I think it needs at least the coin ID (utxo)

[chappjc]

I discovered a very similar issue to the one addressed by this PR, which is the client's 'init' and 'redeem' requests are also blocking as finalizeSwapAction and finalizeRedeemAction wait until the server responds. A server response requires the server to search for the txn, so we have a similar failure mode as we saw with the audits. We should address this without delay.

[chappjc]

@buck54321 The hack I was using to simulate slow wallet AuditContract discovery of the coin is the following right after AuditContract:

if tries < 14 {
	err = asset.CoinNotFoundError
}

[chappjc]

With that rebase, I added one commit (703767f) that adapts the recheck interval to the recently raised default broadcast timeout so that periodic ticks are every 90 seconds (12 minutes / 8 divisions) instead of every 4 minutes (12 minutes / 3 divisions).

The commit also tweaks the checkTrades flow so that the tradeMtx is never locked while a trackedTrade is locked. We don't want the trade map held unnecessarily, especially given the possibility for a trade to remain locked for a significant duration (e.g. finalizeSwapAction). This is fine in checkTrades since once a trade is declared inactive, there's no way it can become active again, so the map access and trade checks do not need to be atomic.