htlcswitch: pipeline pre-images to the incoming link as soon as it's obtained

[Roasbeef]

Today, once we receive a pre-image from the remote party, we don't immediately pipeline it to the incoming link. Instead, we'll wait until we receive a revocation from the remote party as that's when we examine the commitments for updates that have been fully locked in which we can process. If we start to properly pipeline these pre-images, then we'll be able to save some perceived latency of payments (1.5 RTT vs 0.5 RTT), as well as address some scenarios where lost messages may cause us to never settle the HTLC on the incoming link (#2045 ).

Steps To Completion

• Right after we receive the settle, send the pre-image to the switch using the proper circuit identifiers. This achieves pipelining, but introduces other loose ends that need to be tied up.

• With the above change, it's possible to send a duplicate settle to the incoming link. As implement atm, this would cause an error on the incoming link, making it reject that new update. Atm, we don't distinguish between a double settle error, and an invalid pre-image. We'll need to make concrete errors for both these cases to ensure we don't cause any force closes or link failures due to duplicate settles.

[Crypt-iQ]

I can take a look at this