contractcourt: when creating resolveContract closure don't bind to loop variable

In this commit, we fix a long standing bug where at times a co-op
channel closure wouldn't be properly marked as fully closed in the
database. The culprit was a re-occurring code flaw we've seen many times
in the codebase: a closure variable that closes over a loop iterator
variable. Before this instance, I assumed that this could only pop up
when goroutines bind to the loop iterator within a  closure. However,
this instance is the exact same issue, but within a regular closure that
has _delayed_ execution. As the closure doesn't execute until long after
the loop has finished executing, it may still be holding onto the _last_
item the loop iterator variable was assigned to.

The fix for this issue is very simple: re-assign the channel point
before creating the closure. Without this fix, we would go to call
db.MarkChanFullyClosed on a channel that may not have yet actually be in
the pending close state, causing all executions to fail.

Fixes #1054.
Fixes #1056.
Fixes #1075.

contractcourt/chain_watcher.go

@@ -782,11 +782,14 @@ func (c *CooperativeCloseCtx) LogPotentialClose(potentialClose *channeldb.Channe
 // pending closed in the database, then launch a goroutine to mark the channel
 // fully closed upon confirmation.
 func (c *CooperativeCloseCtx) Finalize(preferredClose *channeldb.ChannelCloseSummary) error {
-	log.Infof("Finalizing chan close for ChannelPoint(%v)",
-		c.watcher.chanState.FundingOutpoint)
+	chanPoint := c.watcher.chanState.FundingOutpoint
+
+	log.Infof("Finalizing chan close for ChannelPoint(%v)", chanPoint)
 
 	err := c.watcher.chanState.CloseChannel(preferredClose)
 	if err != nil {
+		log.Errorf("closeCtx: unable to close ChannelPoint(%v): %v",
+			chanPoint, err)
 		return err
 	}