Moved the broadcast functionality to broadcast.[ch]. So far this
includes only the enqueuing side of broadcasts, the dequeuing and
actual push to the peer is daemon dependent. This also adds the
broadcast_state to the routing_state and the last broadcast index to
the peer for the legacy daemon.
This used to be part of `lightningd_state` which is being split up for
the various subdaemons. The main change is the addition of the `struct
routing_state` in `routing.h` and the addition of `rstate` in `struct
lightningd_state` for backwards compatibility.
In particular, 860990fa0afb55f839e882a5e9abe8abe6ccb981 reordered
channel_announcement and c93bf5cf8c48eab1b028e85214cb35feeeffcbb3
reordered the update_fail_malformed_htlc message.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
828eda61df5a7be27051c605f7808e4f690739e4, in particular, it has the
new address format for node_announcement.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It implies tal_count() gives the length. Great for almost all callers which
don't care if there are extra bytes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This removes some redundancy in creating messages, but also allows
a lazy form or parsing without explicitly checking the type.
A helper fromwire_peektype() is added to look up the type and handle
the too-short-for-type problem.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a bit more awkward for large structures, but avoids
indirection for the simpler ones (I copied the structures for the test
code, however). We also remove explicit padding.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Keeping a pointer to the peer that initially sent us a message
could (actually will!) result in dangling pointers. Removing this
results in some additional messages, which will be discarded by the
recipient, so that should not be a problem.
