Allow easy concatenation of bip32 derivation paths

[sgeisler]

Currently one has to convert the path into a Vec<ChildNumber>, extend it and finally convert it back again.

[apoelstra]

warning: unused variable: `path`
   --> /home/apoelstra/dload/code/rust-bitcoin/rust-bitcoin/src/util/bip32.rs:330:26
    |
330 |     pub fn extend(&self, path: impl AsRef<[ChildNumber]>) -> DerivationPath {
    |                          ^^^^ help: if this is intentional, prefix it with an underscore: `_path`
    |
    = note: `#[warn(unused_variables)]` on by default

error[E0502]: cannot borrow `path.0` as mutable because it is also borrowed as immutable
   --> /home/apoelstra/dload/code/rust-bitcoin/rust-bitcoin/src/util/bip32.rs:332:9
    |
332 |         path.0.extend_from_slice(path.as_ref());
    |         ^^^^^^^-----------------^----^^^^^^^^^^
    |         |      |                 |
    |         |      |                 immutable borrow occurs here
    |         |      immutable borrow later used by call
    |         mutable borrow occurs here

error: aborting due to previous error; 1 warning emitted

For more information about this error, try `rustc --explain E0502`.
error: could not compile `bitcoin`.

[elichai]

1. you override the path input variable here

2. why does this create a new DerivationPath instead of extending the current? (I see that child() does the same)

3. why is impl AsRef<[ChildNumber]> better than a simple &[ChildNumber]?

[dr-orlovsky]

Number 3 makes this non-compiling for the current MSRV btw

[sgeisler]

Sorry, fixed.

@elichai:

1. I still wonder how that happened
2. Mainly because I didn't want to mutate the object the method is called on and it fit my use case (would require a lot of clones anyway otherwise) and as you noted other methods like child does it in the same way
3. It allows you to use slices too. I'm inclined to make DerivationPath a trait to extend &[ChildNumber] eventually, it's weird to only have an owned version of it.

[dr-orlovsky]

I think more idiomatic way of doing this may be

    pub fn extend<T: IntoIterator<Item=ChildNumber>>(&self, path: T) -> DerivationPath {
        self.into_iter(0).chain(path).collect()
    }

This will require impl IntoIter for DerivationPath, but this is trivial and will be useful anyway

Also, if you will choose that route, I propose to impl ExactSizeIterator for DerivationPath as well

[sgeisler]

IntoIterator::into_iter would consume self though and I don't know how well vec -> clone -> into_iter -> vec will be optimized to avoid one unnecessary allocation. Would it be that much more idiomatic?

PS: the current travis failure seems related to #468

[elichai]

3. It allows you to use slices too.

Could you give a concrete example of what it will allow that &[ChildNumber] won't?

[apoelstra]

concept ACK. I'm a little ambivalent about using extend as the name when it disagrees with the signature of the standard extend function but otherwise this approach seems fine.

[apoelstra]

Also tested ACK