lightningd/io_loop_with_timers.c: Move mainloop to its own source file, have chaintopology use it

[ZmnSCPxj]

Fixes: #2687

[ZmnSCPxj]

Alternate solution for #2687 is to just fudge the fee estimation at the start.

[ZmnSCPxj]

Missing a #include"../io_loop_with_timers.c" in lightningd/test/run-find_my_abspath.c, will fix after several hours.

[ZmnSCPxj]

For that matter, why does struct plugins have its own timers? Why not just unify it to a single struct timers?

[cdecker]

For that matter, why does struct plugins have its own timers? Why not just unify it to a single struct timers?

I did that to better encapsulate the plugins and make sure we have full control over the timers we create (in the same allocation hierarchy).

[cdecker]

Am I correct in assuming the issue is that we don't process timers when starting the topology, therefore a failed fee estimate or a failed first block fetch will result in us hanging indefinitely?

[ZmnSCPxj]

Am I correct in assuming the issue is that we don't process timers when starting the topology, therefore a failed fee estimate or a failed first block fetch will result in us hanging indefinitely?

Yes, I believe so.

[cdecker]

I took the liberty of add a test that reproduces #2687 first, this way we make sure the fix works and we don't get a regression later :-)

[cdecker]

I'll ack @ZmnSCPxj's part and let someone else ack mine :-)

ACK cb0b9f7

[m-schmoock]

ACK 592db38

Your test 592db38 without the fix properly xfails and demonstates the issue after a timeout of 70 seconds or so. It is also properly fixed by cb0b9f7 . I have some unrelated flakes sometimes okay sometimes not when running locally, but behaves same on master with or without this fix:

• tests/test_connection.py::test_no_fee_estimate (flaky)
• tests/test_plugin.py::test_openchannel_hook (always timeout wait_for ONCHAIN)
• tests/test_misc.py::test_funding_reorg_private (always timeout wait_for_log "Deleting channel")