Use the long-poll client for the startup ping and initial GBT (slow/large templates)

[mblowes]

Problem

On a block-template backend whose getblocktemplate is slow to respond, simplepool can exit at startup and flap in a relaunch loop.

The general-purpose curl client has a 10 s timeout. Two startup calls use it:

1. The ping. When no RPC credentials are set, bitcoind_ping() skips getblockchaininfo (some backends don't implement it) and falls back to a full getblocktemplate. The CUSF bip300301_enforcer is exactly such a backend.
2. The initial template, one step later.

A live template is now multi-megabyte and, once the mempool fills, takes longer than 10 s to return — measured 10.5–13.5 s against alphanet through the enforcer. So the pool exits 3 (bitcoind ping failed: curl: Timeout was reached) or exits 5 (initial GBT failed: …), and a supervisor relaunch loop just flaps until a template happens to come back fast.

Fix

Route those two startup calls through the long-poll client (btc_lp, ~90 s timeout) — the same client the tip watcher already uses for every template. No behaviour change for fast backends; it only removes the 10 s ceiling on the two startup fetches. 16-line change to src/main.c, plus a missing bitcoind_client_free(&btc_lp) on the ping error path.

Found running against the enforcer's GBT server; the enforcer is where the slow, large templates come from.

[rsantacroce]

Hi @mblowes thank you for your collaboration. Can you check why some tests are failing ?

[mblowes]

Thanks @rsantacroce. Those two checks were failing because the branch was based on an older main; I've rebased onto current main. The change is unrelated to the integration/payout paths — it only routes the startup ping and initial getblocktemplate through the existing long-poll client. Build and unit tests pass locally, CI should be green now.