Consider supporting unilateral concludes

[geoknee]

Currently, the only way to do an "instant checkout" and bypass the usual challenge waiting period is if all participants sign an isFinal=true state and submit it via conclude.

We may wish to write applications where one party can force this to happen without the explicit say-so of the other parties. For example, the beneficiary in a unidirectional payment channel may be able to force a transition from an isFinal=false to an isFinal=true state and have that instantly checkout out. This can be (but is not always) safe -- particularly if the other actors cannot force any new transitions without that beneficiary (for example).

It is not clear if we want to support this or not. If we do, we can implement it by having challenge check the candidate.isFinal and set the timeout accordingly. conclude could be removed entirely (in principle).

---

What do you think of separating safety backdoor from conclude by creating some method (e.g. exit), which will resemble option 1, but keep application check in conclude to allow applications, which include different checks if state is marked isFinal.

I'm in favour of separating the two approaches, in principle. However I would prefer:

a) preserve nitro v1 behaviour by having a conclude method requiring unanimous consensus on an isFinal state and skipping the challenge timeout. This gives us the safety backdoor / rapid close of a channel as a core feature which has been tried and tested, and exposes quite a small attack surface.
b) Potentially supporting the new pattern of allowing the challenge period to be skipped if a support proof for an isFinal state is provided, regardless of the signatures in that proof but deferring to the application to make whichever checks it deems appropriate.

We can then consider b separately as a new feature and give it proper scrutiny. Right now it seems to me to add a lot of attack surface / possibility for critical bugs. For example, I think it would introduce a vulnerability into literally all of our existing IForceMoveApps! Furthermore, there don't seem to be so many applications which might make use of b), other than the unidirectional payments (admittedly this may be a widely used IForceMoveApp). Personally, I feel that the tradeoff is not worth it.

Originally posted by @geoknee in #813 (comment)