app: auto-revoke matches when conditions warrant

[itswisdomagain]

Add a trackedTrade.maybeRevoke method to auto-detect and revoke matches that remain in a status longer than expected, and with the expectation/assumption that such matches would have been revoked by the server.

This is an initial attempt at handling cases where a client misses revoke_match messages as described in #643. As mentioned in #643, a complete resolution would likely require adding a new match_status route for detecting revoked matches.

This first pass helps to resolve the following issues identified in #643 relating to revoked matches being considered active by a client:

• prevents clients from taking their next action on a match if the match has been idle for longer than expected.
• makes it possible for clients to auto-redeem counter swaps sooner than later; auto-redemption are not executed for unrevoked matches.
• enable early unlocking of funding and change coins when the last match of an order is revoked before the final swap was sent but the revoke_match request was missed. Without detecting the revocation, such coins would remain locked until client restart. Related client/core,asset: ensure coins are unlocked when no longer needed #648.

Also resolves #629 by triggering swap confirmation checks on tip change rather than on tick.

[itswisdomagain]

Currently, this is only called on tip change as discussed in #629, and while that is preferable, it just occurred to me that trigger on tip change alone might not be sufficient.

If this checkSwapConfirmations method is not called soon after a new block is mined (e.g. if called after 2 new blocks), this client's next step on this match may be delayed beyond the permitted max action window, causing the match to be revoked.

While I'd prefer to not check swap confirmation count multiple times every broadcastTimeout (currently every 20 seconds given a default broadcastTimeout of 1 minute), it might be the safest thing to do. Thoughts?

[chappjc]

I suspect this quickly become obsolete with match_status, which could be implemented with no more complexity than the present solution. Thoughts about the need for these heuristics remaining even with a match_status capability?

Let's pull it out of #513 though, as I think you were planning. Noting that #653 has a commit will set missing matches as revoked on startup. While that doesn't cover zany use cases like computer suspend/resume, I think such an approach is adequate in the interim.

[itswisdomagain]

The only use case I foresee for these heuristics is determining when to send a match_status request. I believe only when there's reason to suspect that a match is idle for too long should we send a match_status request to check if the match is still active or has been revoked. How long to wait / how much idleness is suspicious, is where these heuristics might become relevant with match_status.

[itswisdomagain]

@buck54321 has got a plan for implementing match_status client-side that will not require the estimations done here. I agree this will become largely obsolete once match_status is implemented client-side, so will be closing for now until (if) a use case resurfaces post-match_status-implementation.

Something I'm eager to see, which would not necessarily be resolved by the match_status impl. is preventing clients from taking their next action on a match if the match has been idle for longer than expected. #663 is on course to resolve that.