fix: GatewayLdkClient::info() doesn't rely on esplora

[tvolk131]

Fixes #5965

Ever since adding the ldk gateway to mprocs, it's been significantly slower to fully initialize. To help speed it up, I made #5997 so that the ldk-node::Node instance would manually sync whenever we mined new blocks. This led to a ~8% improvement in just mprocs startup speed. Not bad, but less than I was hoping for. And strangely, even with that change, the startup time for just mprocs was heavily affected by the on-chain sync intervals:

fedimint/gateway/ln-gateway/src/lightning/ldk.rs

Lines 76 to 77 in 06717c0

	onchain_wallet_sync_interval_secs: 10,
	wallet_sync_interval_secs: 10,

It turns out the slowness was because the implementation of ILnRpcClient::info() for the LDK gateway set synced_to_chain to true only if the most recent sync time for the ldk-node::Node instance was more recent than the most recent esplora sync time. This led to synced_to_chain often staying false until another sync was done, even if the node actually was fully synced. This effectively meant we had to wait for the background sync, which is why we couldn't remove the sync interval overrides above.

The solution is to simply use the block height provided by ldk-node::Node::status(). And with this change we can safely delete the sync overrides, preventing spam to the esplora server.

just mprocs startup speed tests on my M1 Pro machine:

Before:
51.7s, 47.2s, 50.5s, 50.1s, 49.7s, 55.1s, 41.7s, 41.9s, 52.2s, 50.5s
Average: 49.06s

After:
35.5s, 35.3s, 35.7s, 34.6s, 34.4s, 37.9s, 36.6s, 33.9s, 36.1s, 35.4s
Average: 35.54s

Average speed improvement of ~28%

[m1sterc001guy]

Why is this being swallowed?

[tvolk131]

I'm still trying to figure out why CI is failing, this was one of the things I tweaked that I thought might fix it. The intention here was to make this function idempotent, since we retry channel opens in devimint:

fedimint/devimint/src/external.rs

Lines 915 to 919 in 004c35d

	// Sometimes channel openings just after funding the lightning nodes don't work right away.
	// This resolves itself after a few seconds, so we don't need to poll for very long.
	poll_with_timeout("Open channel", Duration::from_secs(10), || async {
	gw_a.open_channel(&gw_b, 10_000_000, Some(push_amount)).await.map_err(ControlFlow::Continue)
	})

I believe calling ConnectPeer on a peer that's already connected returns an error.