Store failcode of local forward failure into DB (completed)

[trueptolemy]

Store failcode of local forward into DB, and thus listforwards will show the failcode for local failed forwarding payment.(issue #2435 )

• Add a new status for forward payment: FORWARD_LOCAL_FAILED.
  It means we meet failure locally, and we can fetch and store the failcode.

• Add failcode field in forwarded_payments table;

• Add failcode arugument in function wallet_forwarded_payment_add();

• Store local failure in forward process by calling wallet_forwarded_payment_add();

Here are 5 case I think we should handle as local_failed:

Case 1. When Msater resolves the reply about the next peer infor(sent by Gossipd), and need handle unknown next peer failure in channel_resolve_reply().

Test for this case: I ask l1 pay to l3 through l2 but close the channel between l2 and l3 after getroute(), the payment will fail in l2 because of WIRE_UNKNOWN_NEXT_PEER;

Case 2. When Master handle the forward process with the htlc_in and the id of next hop, it tries to drive a new htlc_out but fails in forward_htlc().

Test for this case: I ask l1 pay to 14 through with no fee, so the payment will fail in l2 becase of WIRE_FEE_INSUFFICIENT;

Case 3. When we send htlc_out, Master asks Channeld to add a new htlc into the outgoing channel but Channeld fails. Master need handle and store this failure in rcvd_htlc_reply().

Test for this case: I ask l1 pay to l5 with 10^8 sat through the channel (l2-->l5) with the max capacity of 10^4 msat , the payment will fail in l2 because of CHANNEL_ERR_MAX_HTLC_VALUE_EXCEEDED;

Case 4. When Channeld receives a new revoke message, if the state of corresponding htlc is RCVD_ADD_ACK_REVOCATION, Master will tries to resolve onionpacket and handle the failure before resolving the next hop in peer_got_revoke().

Test for this case: I ask l6 pay to l4 through l1 and l2, but we replace the second node_id in [route] with the wrong one, so the payment will fail in l2 because of WIRE_INVALID_ONION_KEY;

Case 5. When Onchaind finds the htlc time out or missing htlc, Master need handle these failure as FORWARD_LOCAL_FAILED in if it's forward payment case.

Test for this case: I ask l1 pay to l4 through l2 with the amount less than the invoice(the payment must fail in l4), and we also ask l5 disconnected before sending update_fail_htlc, so the htlc will be holding until l2 meets timeout and handle it as local_fail.

EDIT: The last commit in Heisei era.

[trueptolemy]

Hi! @cdecker I've done. What do you think about? Thank you!

[cdecker]

Removed the WIP tag, will review asap

[cdecker]

Just two minor cleanups:

• Reordering the sqlite3_bind_* calls would simplify the if-else-statements
• Reordering commits would fix bisectability

In addition I'd like to fix the JSON-output to be machine readable.

[cdecker]

ACK 88a28d5