feat: Add derivation path child and extend methods

[ItoroD]

Description

Added more methods for the derivation path type. Below are 4 convenient methods I have chosen to leave out and why.

into_child : This does the same thing child does except that one consumes self and the other clones. This will not make a difference on bindings level.

children_from ,normal_children and hardened_children

1. The methods below return iterators and if we try to collect them in a vec like we often do for other methods, application crashes as it tries to collect for all possible indexes of a u32.
2. When dealing with potentially large or infinite sequences (like derivation paths), returning a pre-allocated Vec is inefficient and forces the caller to guess how many items they need upfront.

The above 3 can still be performed by the using using the child method. Which is more idiomatic. (as long as the state of param is maintained properly)

Notes to the reviewers

Documentation

• bdk_wallet
• bitcoin
• uniffi
• Other:

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 a changelog in the next release tracking issue (see example)
• 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

[thunderbiscuit]

This is looking good!

Because it's a simple type and methods I'd love to see a few tests that would play around with the DerivationPath type. Would you mind adding a few, at least on the Android tests?

[ItoroD]

This is looking good!

Because it's a simple type and methods I'd love to see a few tests that would play around with the DerivationPath type. Would you mind adding a few, at least on the Android tests?

Sure! I could add those. I did add some tests to the rust side before now. But its good to see it on bindings side too!

[reez]

Should this validate ChildNumber before converting? ChildNumber exposes raw u32, so callers can pass index >= 2^31 and we’ll build a non‑BIP32 path. Upstream has from_normal_idx/from_hardened_idx maybe child should return Result and use those checked constructors

[ItoroD]

Shouldn't a caller be able to enter an index >= 2^31 ? Those are hardened path. The child method will treat it as such.

EDIT - SMH. I see now

[reez]

When I was looking at https://github.com/rust-bitcoin/rust-bitcoin/blob/bitcoin-0.32.8/bitcoin/src/bip32.rs#L124-L162 I didnt think so, I was reading it as both Hardened and Normal required under that

[reez]

Should this be TryFrom using the checked constructors to enforce the BIP32 index range? Right now any u32 passes through

[reez]

I think if you set childIndex to 2147483648u and then add assertFailsWith<Exception> { DerivationPath(childDerivationPath.toString()) } it could fail because the path can be constructed but not parsed back because I think we’re bypassing the BIP32 index checks?

[ItoroD]

Ahh! that is a dangerous catch! Thanks! I will address this tomorrow

[reez]

sounds good, overall this pr is looking good though 👍

[ItoroD]

Made some updates. Added new test in relation to these changes too checkInvalidNormalChildNumberFails and checkInvalidHardenedChildNumberFails