Don't wrap around when deriving an extended key at a too large depth

[darosior]

trafficstars

We would previously silently wrap the derived child's depth back to 0. Instead, explicitly fail when trying to derive an impossible depth, and handle the error in callers.

An extended fuzzing corpus of descriptor_parse triggered this behaviour, which was reported by MarcoFalke.

Fixes #25751.

[luke-jr]

Is the wrap actually harmful?

In any case, current code will never do this, right?

[darosior]

It is harmful in the sense that this behaviour is not specified by BIP32. We could accept an invalid descriptor or xpub that another software would refuse (or worse, treat differently).

In any case, current code will never do this, right?

Well, it was triggered by current code.

[achow101]

ACK 84f86dcc1d9ff6f3161c9567068216d7b27d3b39

[achow101]

re-ACK fb9faffae3a26b8aed8b671864ba679747163019

[instagibbs]

Hadn't occurred to me this implicit limit due to the encoding of xpub/xprv.

utACK https://github.com/bitcoin/bitcoin/pull/25642/commits/fb9faffae3a26b8aed8b671864ba679747163019