BOLT 4: add capacity_order to temporary_channel_failure.

With AMP, we'll effectively be probing for channel
capacity.  Returning how far out a payment was provides
a hint.

You can determine the order required, then fuzz it a
little, eg:

    switch(rand(8)):
    case 0: increase, retry;
    case 1: decrease, retry;
    case 2-8: stop;

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

04-onion-routing.md

@@ -766,9 +766,12 @@ The ephemeral key was unparsable by the processing node.
 2. data:
    * [`u16`:`len`]
    * [`len*byte`:`channel_update`]
+   * [`u8`:`capacity_order`] (`option_capacity_order`)
 
 The channel from the processing node was unable to handle this HTLC,
-but may be able to handle it, or others, later.
+but may be able to handle it, or others, later.  The optional
+`capacity_order` field gives a very rough indication of how far over
+the channel capacity this htlc amount was.
 
 1. type: PERM|8 (`permanent_channel_failure`)
 
@@ -918,6 +921,8 @@ A _forwarding node_ MAY, but a _final node_ MUST NOT:
   transient error occurs in the outgoing channel (e.g. channel capacity reached,
   too many in-flight HTLCs, etc.):
     - return a `temporary_channel_failure` error.
+	- MAY set `capacity_order` to the approximate number of powers of 2 that the HTLC amount exceeded the available capacity.
+	- SHOULD randomize `capacity_order`.
   - if an otherwise unspecified, permanent error occurs during forwarding to its
   receiving peer (e.g. channel recently closed):
     - return a `permanent_channel_failure` error.