BOLT#02: clarify coop close requirements

This commit ensures closing_signed can only begin if there are
no dangling commitments. It also clarifies update_fee requirements
if it is sent after shutdown.

02-peer-protocol.md

@@ -544,10 +544,10 @@ A sending node:
   - if it hasn't sent a `funding_created` (if it is a funder) or a `funding_signed` (if it is a fundee):
     - MUST NOT send a `shutdown`
   - MAY send a `shutdown` before a `funding_locked`, i.e. before the funding transaction has reached `minimum_depth`.
-  - if there are updates pending on the receiving node's commitment transaction:
+  - if there are uncommitted updates pending on the receiving node's commitment transaction:
     - MUST NOT send a `shutdown`.
   - MUST NOT send an `update_add_htlc` after a `shutdown`.
-  - if no HTLCs remain in either commitment transaction:
+  - if neither side has a dangling commitment and neither commitment contains any HTLCs (including dust HTLCs):
     - MUST NOT send any `update` message after a `shutdown`.
   - SHOULD fail to route any HTLC added after it has sent `shutdown`.
   - if it sent a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`:
@@ -580,10 +580,10 @@ shutdown starts, the question of how to behave if it wasn't is avoided:
 the sender always sends a `commitment_signed` first.
 
 As shutdown implies a desire to terminate, it implies that no new
-HTLCs will be added or accepted.  Once any HTLCs are cleared, the peer
+HTLCs will be added or accepted.  Once any HTLCs are cleared, there are no dangling commitments and all updates are included on both commitment transactions, the peer
 may immediately begin closing negotiation, so we ban further updates
 to the commitment transaction (in particular, `update_fee` would be
-possible otherwise).
+possible otherwise). However, while there are HTLCs on the commitment transaction, the initiator may find it desirable to increase the feerate as there may be pending HTLCs on the commitment which could timeout.
 
 The `scriptpubkey` forms include only standard segwit forms accepted by
 the Bitcoin network, which ensures the resulting transaction will
@@ -602,7 +602,7 @@ The `shutdown` response requirement implies that the node sends `commitment_sign
 
 ### Closing Negotiation: `closing_signed`
 
-Once shutdown is complete and the channel is empty of HTLCs, the final
+Once shutdown is complete, the channel is empty of HTLCs, there are no dangling commitments and all updates are included on both commitments, the final
 current commitment transactions will have no HTLCs, and closing fee
 negotiation begins.  The funder chooses a fee it thinks is fair, and
 signs the closing transaction with the `scriptpubkey` fields from the