Drop system clock calls for PendingHTLCsForwardable events.

[TheBlueMatt]

Instead, return a Duration and let the user do the work of waiting.
This is one of only a handful of steps to make us
mostly-syscall-free, at least enough to run in WASM according to
elichai.

• 1 extra commit to remove an entirely-useless field in channel that relied on Instant::now().

[elichai]

Cool :)

[elichai]

It's still calling SystemTime in the Key interface (https://github.com/rust-bitcoin/rust-lightning/blob/master/src/chain/keysinterface.rs)

[ariard]

ACK e2a9ed7, comments are already there API design issues.

That's cool, user can still hack its own monotonic counter if he can't rely on time syscall and wrappers

[ariard]

Just to be sure, timeout here is only relevant if you are last peer in the payment route, don't have the preimage and can initiate the canceling walk back?

[ariard]

And furthermore, I've a doubt where the cltv_expiry field of AddHTLC should be used in our API, I mean we have fail_htlc_backwards, which is public but how API consumer is leaded to be aware of delay ?

[TheBlueMatt]

These are HTLCs which we accepted for relay but which we have not yet added to the outbound channel (as we were waiting for a remote revoke_and_ack at the time we received them, or were otherwise unable to forward them). AFAIR, we will never fail these HTLCs backwards as the ChannelMonitor isn't even aware of them at this time.

[ariard]

Okay gotcha, not implemented yet, it's going with other TODO in Channel::update_add_htlc, need to pass height in process_pending_htlc_forwards I guess

[TheBlueMatt]

I think we can just fail them backwards if they're still waiting to be forwarded as the CLTV starts to get close in a hook from block_connected.

[TheBlueMatt]

@elichai right, I'm aware, I have an alternative to #352 which also drops most of the rng usage inside the library and fixes that then coming up soon.