Do not unnecessarily retransmit commitment_signed in dual funding

On reconnection in the middle of the dual-funding flow, if both
nodes have exchanged the initial `commitment_signed` and node A
had sent its (initial) `tx_signatures` but node B never received
them, both nodes should send a `channel_reestablish` with
`next_funding_txid` set and a `next_commitment_number` of 1 (as
they've already received the commitment transaction for commitment
number 0).

The spec indicates in this case that both nodes should retransmit
their `commitment_signed`, however, as this is only gated on
`next_funding_txid` and not the `next_commitment_number` field.
This may cause implementations which assume that each new
`commitment_signed` is for a new state to fail and potentially
fail the channel.

Instead, we should rely both the presence of `next_funding_txid`
*and* `next_commitment_number` being zero to decide if we need to
resend our `commitment_signed`. Sadly, we cannot rely on just
`next_commitment_number` as that is used to request a force-closure
in a non-standard way to work around implementations not honoring
the `error` message.

02-peer-protocol.md

@@ -2482,12 +2482,8 @@ A node:
   the last `commitment_signed` message the receiving node has sent:
     - MUST reuse the same commitment number for its next `commitment_signed`.
   - otherwise:
-    - if `next_commitment_number` is not 1 greater than the
-  commitment number of the last `commitment_signed` message the receiving
-  node has sent:
-      - SHOULD send an `error` and fail the channel.
-    - if it has not sent `commitment_signed`, AND `next_commitment_number`
-    is not equal to 1:
+    - if `next_commitment_number` is not equal to the commitment number of the
+      next `commitment_signed` the receiving node will send:
       - SHOULD send an `error` and fail the channel.
   - if `next_revocation_number` is equal to the commitment number of
   the last `revoke_and_ack` the receiving node sent, AND the receiving node
@@ -2520,6 +2516,7 @@ A receiving node:
   - if `next_funding_txid` is set:
     - if `next_funding_txid` matches the latest interactive funding transaction:
       - if it has not received `tx_signatures` for that funding transaction:
+        - if `next_commitment_number` is zero:
           - MUST retransmit its `commitment_signed` for that funding transaction.
         - if it has already received `commitment_signed` and it should sign first,
           as specified in the [`tx_signatures` requirements](#the-tx_signatures-message):