ld: We might not have a failing channel if localfail and sendonion

This happens to be an edge case with the way we use `sendonion` in
MPP. `sendonion` does not attempt to recover the route even if we supply the
shared secrets (it'd require us to map forwarding channels to the nodes etc),
so `failnode` will always be unset, unless it is the first hop, which gets
stored. This is not a problem if it weren't for the fact that we don't store
the partial route, consisting solely of the channel leading to the first hop,
therefore the assertion that either both are NULL or both aren't fails on the
first hop.

This went unnoticed since with MPP we have more concurrent payments in flight,
increasing the chances of a exhausted first hop considerably.

lightningd/pay.c

@@ -701,15 +701,20 @@ static struct command_result *wait_payment(struct lightningd *ld,
 		} else {
 			/* Parsed onion error, get its details */
 			assert(failnode);
-			assert(failchannel);
 			fail = tal(tmpctx, struct routing_failure);
 			fail->erring_index = failindex;
 			fail->failcode = failcode;
 			fail->erring_node =
 			    tal_dup(fail, struct node_id, failnode);
-			fail->erring_channel =
-			    tal_dup(fail, struct short_channel_id, failchannel);
-			fail->channel_dir = faildirection;
+
+			if (failchannel) {
+				fail->erring_channel = tal_dup(
+				    fail, struct short_channel_id, failchannel);
+				fail->channel_dir = faildirection;
+			} else {
+				fail->erring_channel = NULL;
+			}
+
 			/* FIXME: We don't store this! */
 			fail->msg = NULL;