Make bitcoind optional: add transaction-sync as an alternative chain backend

[bitwalt]

Implements #125.

Reworked per @zoedberg's review: instead of replacing lightning-block-sync with lightning-transaction-sync, this adds transaction-sync as an alternative chain backend and keeps block-sync intact. The sync mode is chosen explicitly at unlock time.

Sync modes

The /unlock payload gains a sync_mode tag:

• block_sync (default): consume full blocks from a trusted/local bitcoind over JSON-RPC (lightning-block-sync). The bitcoind_rpc_* parameters live inside this variant, so they are required exactly when this mode is selected and rejected otherwise — no manual "all or none" validation. This is the more trust-minimized / local-first option.
• transaction_sync: sync through the configured electrum/esplora indexer_url (lightning-transaction-sync). No bitcoind required — lighter to deploy for indexer-based setups.

Cargo features

Each backend is gated behind a feature (block-sync, transaction-sync), both enabled by default, so a user who wants only one sync type can build with only the dependency they need. Both single-feature builds compile cleanly, and requesting a mode that wasn't compiled in returns a clear error.

Implementation notes

• LDK is wired against trait objects for the fee estimator, broadcaster and gossip UTXO lookup, so a single set of type aliases serves both backends.
• Because lightning-block-sync's GossipVerifier requires the P2PGossipSync to be typed with Arc<Self>, a small BlockSyncGossipVerifier provides the block-sync gossip UTXO lookup against the shared trait-object gossip sync (mirroring the transaction-sync IndexerGossipVerifier).

Tests

Adds an integration test for the transaction-sync backend (as suggested): two nodes are unlocked in transaction-sync mode, an RGB asset channel is opened, a node is restarted (re-establishing the channel after syncing via the indexer) and the channel is cooperatively closed. The existing block-sync tests continue to pass unchanged.

[zoedberg]

Please check my comment #125 (comment), I explained why we should not replace the block-sync with the transaction-sync but add it instead as an alternative sync mode. Please update this PR accordingly

[zoedberg]

Hi @bitwalt, here #125 (comment) you said you agreed in updating this PR to add this as an alternative sync mode. Are you still willing to complete this PR?

[bitwalt]

Hi Zoe, sure I'll try to complete this

[bitwalt]

Thanks @zoedberg — I've reworked the PR along the lines you suggested.

Rather than replacing block-sync, it now keeps lightning-block-sync and adds lightning-transaction-sync as an alternative, selectable via an explicit sync_mode on the unlock request:

• block_sync (default) — full blocks from a trusted/local bitcoind. The bitcoind_rpc_* params are embedded in this variant so they're required exactly when this mode is chosen (no manual all-or-none checking).
• transaction_sync — sync through the configured electrum/esplora indexer only, no bitcoind.

Both are behind Cargo features (block-sync, transaction-sync), enabled by default, so a user can compile just the sync dependency they want; both single-feature builds compile cleanly.

I added the integration test you described (unlock 2 nodes, open a channel, restart a node, close the channel) exercising the transaction-sync path, and the existing block-sync tests still pass.

Two notes for review:

1. The /unlock payload shape changes (the bitcoind params now sit under the sync_mode: block_sync variant). You mentioned not worrying about existing setups in this phase, but happy to reshape if you'd prefer a different layout.
2. For the block-sync gossip UTXO lookup I added a small BlockSyncGossipVerifier instead of lightning-block-sync's GossipVerifier, because the latter requires the P2PGossipSync to be typed with Arc<Self>, which is incompatible with the trait-object gossip sync needed to serve both backends from one PeerManager type. Let me know if you'd rather approach that differently.