Adopt TORv2 addresses about rust-lnpbp

[Kixunil]

Would it be possible to disregard the distinction between addresses and just defer to torut::OnionAddress/torut::TorPublicKey?

[dr-orlovsky]

Good news! Lets try to remove Copy on InetAddr and see how much problems we will get after

[rajarshimaitra]

Opened the PR. @Kixunil would appreciate your review. So far it can only parse onion v2 from an address string.

[dr-orlovsky]

Hard to say... We do distinguish IPv4 from IPv6 in the enum, so at least at that level it would be nice to distinguish TORv2 from TORv3.

Don't spend time on this issue, I left it for new contributors b/c it's very simple to implement as a first issue

[Kixunil]

Sure, was just randomly looking around and noticed it because I had to look into torut to implement parse_arg properly. :)

[rajarshimaitra]

If this issue is still open, I am willing to work on it.

Small note after initial look, torut doesn't seem to support TorPubKeyV2 to OnionAddressV2 conversion. As we are only storing the publickeys in the structure do we plan to implement the conversion too? Or there are other ways of doing it?

[dr-orlovsky]

It is still open, you are welcome to pick it!

As for V2, I think we only need to support OnionAddressV2, w/o support for TorPubKeyV2

[rajarshimaitra]

Ok, I went some distance and so far it seems workable.

Need some technical help. OnionAddressV2 from torut doesn't implement Copy. This is causing error in #[derive(Copy)] for InetAddr which wraps over OnionAddressV2. I cant manually implement Copy as OnionAddressV2 is from an external crate.
One option is to disable Copy derivation on InetAddr but that will cause ripple effects upstream.

So what's the best way to fix this situation?

[Kixunil]

@rajarshimaitra What about a PR against torut for the address to implement Copy?

[dr-orlovsky]

We can do that for sure, but I expect there are some limitations b/c of the key structure such that Copy is unreasonable?

[rajarshimaitra]

@rajarshimaitra What about a PR against torut for the address to implement Copy?

@Kixunil I thought of the same at first. But the OnionAddressV3 also doesn't implement copy. So there is probably something with it as @dr-orlovsky suggested.

Good news! Lets try to remove Copy on InetAddr and see how much problems we will get after

I gave a try at removing Copy derivations. The changes ripples through few more modules of the library, but nothing major. Not sure about the rgb node though. There might be more dependency on it.

[Kixunil]

such that Copy is unreasonable?

I wonder why though, keys should be representable as a fixed-length array of bytes, which is always Copy...