Implement PendingHTLCsRelayable Event to split acceptance/relay checks

[ariard]

Currently, we apply both BOLT-2 incoming channels settings checks and BOLT-4 relay checks at update_add_htlc reception. We should split relay checks and get incoming HTLC acceptance generate a Event::PendingHTLCsRelayable. This event could be consumed by process_pending_htlc_relayable and should generate a PendingHTLCsForwardable. In between any kind of client custom function can be implemented support for stricter relay policy, on-the-flight generated outgoing zero-conf channel, delayed relay, trampoline-style of routing, ...

See further #670 and http://gnusha.org/rust-bitcoin/.

[TheBlueMatt]

This could also allow live-rebalancing on the client's end, which would be cool.

[ariard]

Also fix current bug : #633 (comment)

[TheBlueMatt]

Note that the bug at #633 (comment) has been fixed in #690.

[ariard]

Might serve to address few timing attacks : #975 (comment)

[ariard]

Might serve as iptables for routing nodes : #975 (comment)

[ariard]

Maybe also addressing that at the same time : #1119 (comment)

[TheBlueMatt]

May need to rely on #1302

[TheBlueMatt]

Turns out we're not gonna rely on this for #1302, so there's no reason for this to have a very-soon milestone.