feat(electrum): add config based client constructor

[reez]

Description

Exploration of #1037

Add an ElectrumClientConfig record and explicit connect constructor so bindings can pass around Electrum connection settings before constructing the blocking client

Notes to the reviewers

Documentation

• bdk_wallet
• bitcoin
• uniffi
• Other:

Changelog

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing
• I've added exactly one changelog:* label
• I've linked the relevant upstream docs or specs above

New Features:

• I've added tests for the new feature
• I've added docs for the new feature

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[thunderbiscuit]

I looked into this a bit and agree a fix would be great! I think maybe the issue is at the rust-electrum-client level however, where the constructor makes that network call instead of doing a sort of lazy connection on the first sync, or maybe adding a new method to check the server connection or something. I'll investigate this a bit more on my side too!

bitcoindevkit/rust-electrum-client#212

[reez]

I looked into this a bit and agree a fix would be great! I think maybe the issue is at the rust-electrum-client level however, where the constructor makes that network call instead of doing a sort of lazy connection on the first sync, or maybe adding a new method to check the server connection or something. I'll investigate this a bit more on my side too!

bitcoindevkit/rust-electrum-client#212

totally, my first step was figuring out what we could do here on ffi for the upcoming 3.1 (I feel like what I have stood out to me as best/clearest api), and I was still thinking thru what I thought the best idea on upstream electrum-client was so thanks for opening that issue to get it started 👍

[j-kon]

Thanks for working on this. I like the direction of introducing ElectrumClientConfig because it gives bindings a cleaner way to pass connection settings around before constructing the blocking client.

I also like that the existing constructor now delegates to ElectrumClient::connect(...), which keeps the old API path while avoiding duplicated builder logic.

One question: should we add a small test for the new config-based constructor? Since this PR adds a new public binding-facing constructor, a focused test using the same config values as the existing constructor would help prove both paths stay equivalent.

Also, for downstream bindings, it may be useful to clarify whether validate_domain is intentionally required instead of optional with a default. The other config fields are optional, but validate_domain must always be passed, so I just want to make sure that is the intended API shape.