Improve reliability of wait_and_check_bitcoind

[NicolasDorier]

bitcoin-cli -rpcwait works probably as expected if the blocks are loading before core lightning start. But doesn't if BitcoinD isn't listening at all before Core Lightning wait, we observed the following behavior.

• Timestamp: 0: Core Lightning Starts and wait RPC
• Timestamp: 10: Bitcoind starts
• Timestamp: 30: Core Lightning fails (RPC connection timed out)
• Timestamp: 31: Core Lightning Container crashes, docker restart it
• Timestamp: 32: Core Lightning Starts, AND detect bitcoind started

Rather than waiting for 30 seconds, this PR wait 30 times for 1 seconds. This fix the issue for us.

• Timestamp: 0: Core Lightning Starts and wait RPC
• Timestamp: 10: Bitcoind starts
• Timestamp: 11: Core Lightning detect bitcoind started

This is a patch we are using in BTCPay Server deployments. Not really critical in production scenario, but it was causing our tests to fail as lightningd was taking 30 seconds to properly start.

[nGoline]

Nice fix there. I just have 2 small changes before approving.

[nGoline]

Thanks, both review points are addressed. Normally I'd just fold these fixups and rebase it myself before merging, but the fork is under the btcpayserver org, and GitHub doesn't allow maintainer pushes to org-owned fork branches (the "allow edits by maintainers" flag has no effect there). So this last bit is on you.

Could you tidy the history so it lands as a single commit on top of current master? Right now it has the two Update plugins/bcli.c suggestion commits plus a merge commit. Please fold the updates into the main commit and rebase instead of merging. This is what I'd run:

git rebase -i master
# keep "pick" on "Improve reliability of wait_and_check_bitcoind"
# change the two "Update plugins/bcli.c" lines to "fixup"
git push --force

The rebase drops the merge commit for you, so you'll end with one commit on latest master. Then I'll approve and merge it.