BOLT #2: bad update_fee after shutdown when all HTLCs cleared.

I got an unexpected update_fee message after `shutdown` exchange,
which is currently legal:

A: shutdown (no htlcs)
                          B: receive shutdown
                          B: reply with shutdown & closing_signed

A: send update_fee & commitment_signed
A: receive shutdown

Simplest to ban any updates (currently, just update_fee) from adding a
new commitment tx while we're at the end of shutdown.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

02-peer-protocol.md

@@ -418,6 +418,8 @@ A sending node:
   - if there are 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:
+	- 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`:
     - MUST send the same value in `scriptpubkey`.
@@ -448,7 +450,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.
+HTLCs will be added or accepted.  Once any HTLCs are cleared, the peer
+may immediately begin closing negotiation, so we ban further updates
+to the commitment transaction (in particular, `update_fee` would be
+possible otherwise).
 
 The `scriptpubkey` forms include only standard forms accepted by the
 Bitcoin network, which ensures the resulting transaction will