Drop the required channel_update in failure onions

As noted previously, `channel_update`s in the onion failure packets
are massive gaping fingerprintign vulnerabilities - if a node
applies them in a publicly-visible way the err'ing node can easily
identify the sender of an HTLC.

While the updates are still arguably marginally useful for nodes to
use in their pathfinding local to retires of the same payment, this
too will eventually become an issue with PTLCs. Further, we
shouldn't be letting nodes get away with delaying payments by
failing to announce the latest channel parameters or enforcing new
parameters too soon, so treating the node as having indicated
insufficient liquidity (or other general failure) is appropriate
in the general case.

Thus, here, we begin phasing out the `channel_update` field,
requiring nodes ignore it entirely and making it optional (though
obviously nodes should still provide it for some time).

04-onion-routing.md

@@ -1080,12 +1080,7 @@ The top byte of `failure_code` can be read as a set of flags:
 * 0x8000 (BADONION): unparsable onion encrypted by sending peer
 * 0x4000 (PERM): permanent failure (otherwise transient)
 * 0x2000 (NODE): node failure (otherwise channel)
-* 0x1000 (UPDATE): new channel update enclosed
-
-Please note that the `channel_update` field is mandatory in messages whose
-`failure_code` includes the `UPDATE` flag. It is encoded *with* the message
-type prefix, i.e. it should always start with `0x0102`. Note that historical
-lightning implementations serialized this without the `0x0102` message type.
+* 0x1000 (UPDATE): channel forwarding parameter was violated
 
 The following `failure_code`s are defined:
 
@@ -1378,12 +1373,21 @@ In the case of multiple short_channel_id aliases, the `channel_update`
 expecting, to both avoid confusion and to avoid leaking information
 about other aliases (or the real location of the channel UTXO).
 
+The `channel_update` field used to be mandatory in messages whose `failure_code`
+includes the `UPDATE` flag. However, because nodes applying an update contained
+in the onion to their gossip data is a massive fingerprinting vulnerability,
+the `channel_update` field is no longer mandatory and nodes are expected to
+transition away from including it. Nodes which do not provide a
+`channel_update` are expected to set the `channel_update` `len` field to zero.
+
+
 ## Receiving Failure Codes
 
 ### Requirements
 
 The _origin node_:
   - MUST ignore any extra bytes in `failuremsg`.
+  - MUST ignore the `channel_update` field.
   - if the _final node_ is returning the error:
     - if the PERM bit is set:
       - SHOULD fail the payment.
@@ -1397,20 +1401,8 @@ The _origin node_:
       - SHOULD remove all channels connected with the erring node from
       consideration.
     - if the PERM bit is NOT set:
-      - SHOULD restore the channels as it receives new `channel_update`s.
-    - otherwise:
-      - if UPDATE is set, AND the `channel_update` is valid and more recent
-      than the `channel_update` used to send the payment:
-        - if `channel_update` should NOT have caused the failure:
-          - MAY treat the `channel_update` as invalid.
-        - otherwise:
-          - SHOULD apply the `channel_update`.
-        - MAY queue the `channel_update` for broadcast.
-      - otherwise:
-        - SHOULD eliminate the channel outgoing from the erring node from
-        consideration.
-        - if the PERM bit is NOT set:
-          - SHOULD restore the channel as it receives new `channel_update`s.
+      - SHOULD restore the channels as it receives new `channel_update`s from
+        its peers.
     - SHOULD then retry routing and sending the payment.
   - MAY use the data specified in the various failure types for debugging
   purposes.