Support multipath descriptors

[notmandatory]

Describe the enhancement

The release of rust-miniscript 10.0.0 has multipath descriptor support. We should support this also in bdk 1.0 and backported to a bdk 0.2X (maintenance) release.

Use case

See bitcoin/bitcoin#17190

Additional context

This was requested by @andreasgriffin for his project bitcoin-safe.

BIP-389

[tillkolter]

Any timeline on this?

[notmandatory]

This most likely will end up in a 2.0 release some time next year.

[notmandatory]

For reference: bitcoin/bitcoin#22838

I think we may be able to add this feature in a 1.x release since we added single descriptor wallet support back in bitcoindevkit/bdk#1533.

[notmandatory]

Also requested by AnchorWatch.

[ValuedMammal]

If we offer a wallet constructor that accepts a multipath descriptor, should bdk also be prepared to parse a multipath descriptor from the loaded change set? or for simplicity should the descriptor always be split into parts before staging?

[ValuedMammal]

I discussed with notmandatory the possibility of enhancing the existing create_single method to accommodate a multipath descriptor rather than add another constructor. The wallet would behave the same as if you divided the multipath into single-derivation path descriptors and used Wallet::create like normal.

[thunderbiscuit]

I didn't mean to shut down bitcoindevkit/bdk#1906 with my questions! haha. I hope this is still on the table.

From an API design point of view, my take on this is that I need (somewhere, doesn't need to be in the constructor but feels most natural there for me) to have certainties about the number of keychains the wallet I'm about to create will have. Uncertainties there will lead to inconsistencies, for example:

1. If I use Wallet::create_single and expect a wallet with 1 keychain but the user-provided string was a multipath descriptor and the Wallet creates 2 keychains, it will start using the change keychains in methods where that keychain can be used (transaction building, balance, etc.), but I don't know this or at least don't expect it to. Backups and use of this wallet on other software might not yield what I expect (my workflow is centered on 1 keychain, the wallet in fact uses two against my will).
2. If I use Wallet::create_multipath (name tbd I think) and the multipath is say 5 indices, I really need Wallet to start tracking all 5 keychains or return an error stating that more than 2 keychains is not supported. If the wallet silently drops the 3rd, 4th, and 5th keychains, balance and transaction history will not match potential other wallets/software that use this multipath descriptor. For 1.0 since we don't intend to provide more than 2 descriptor per wallet functionality, I would error out (maybe same if the multipath descriptor expands to only 1? not sure about this one).

[notmandatory]

I'm OK with adding a new constructor for multipath wallets if you all think it makes more sense.