Allow close and dev-fail to work on channels in state awaiting_lockin

[cdecker]

Many of the channel failures that we see are because of the channel not progressing beyond awaiting_lockin. close and dev-fail currently do not work on channels in that state, but I think they should.

[ZmnSCPxj]

Hi @cdecker @rustyrussell, what are plans for this? I am afraid I do not know much about the channel opening process.

Presumably there are a number of reasons why things are getting stuck in CHANNELD_AWAITING_LOCKIN. So if dev-fail/close is done in CHANNELD_AWAITING_LOCKIN:

1. I think, we should consider to broadcast two transactions:
   1. The commitment transaction or the bilateral close transaction (depending on which command is being done).
   2. An RBF transaction that spends all UTXO that the original funding transaction spent and pays it to an address we control.
2. Afterwards, we can monitor which transaction gets confirmed.

The reason for also broadcasting the other transaction is that possibly the original funding transaction is stuck for many possible reasons:

1. It never got broadcast due to minimum relay fee.
2. Our local estimatesmartfee was not being smart and gave a low fee that will not be confirmed during a period of high block space usage.
3. Majority miners encouraging high fees by increasing their minimum relay fee.

Possibly in this case, we can try broadcasting the commitment/mutual close first, wait for some time, then if it does not confirm quickly enough, simply abort and use the fee-bumped re-spend transaction and forget the channel.

[ZmnSCPxj]

Possibly blocked by #1308, which is a crash due to a state jump from CHANNELD_AWAITING_LOCKIN to CLOSINGD_SIGEXCHANGE. If we support a close during CHANNELD_AWAITING_LOCKIN we should have a proper transition from CHANNELD_AWAITING_LOCKIN to CHANNELD_SHUTTING_DOWN.

[rustyrussell]

This is partially fixed in #1313 but I didn't address dev-fail...

[ZmnSCPxj]

dev-fail simply calls channel_internal_error. Basic read of the code suggests it should work even in awaiting lockin state; I am uncertain if the claim "dev-fail currently do not work on channels in that state" is correct.

Perhaps the reason why dev-fail apparently does not work, is in the case:

1. We are in awaiting lockin state.
2. The counterparty is unreachable.
3. We have an error cached and we even have broadcast our unilateral close, but until the counterparty is reachable we cannot move state away for awaiting lockin.

Is this the situation where dev-fail does not work?

[rustyrussell]

Indeed, this is true, and I've added a test for the new closing force=true for this case. Closing.