Clarify refund address input docs

[danielgranhao]

This adds documentation suggesting that integrators provide a refund address as parsed by the parse method.

Also, it fixes some warnings from cargo doc.

[dangeross]

Isn't it better for the SDK to validate the address? we have a fn for it validate_bitcoin_address()

[danielgranhao]

Isn't it better for the SDK to validate the address? we have a fn for it validate_bitcoin_address()

We can (and maybe should) do that, but IMO it's still a good practice for integrators to use the output of parse. We can even go a step further and switch the refund_address type from String to BitcoinAddressData, which would further motivate the use of parse. Wdyt?

[dangeross]

We can (and maybe should) do that, but IMO it's still a good practice for integrators to use the output of parse. We can even go a step further and switch the refund_address type from String to BitcoinAddressData, which would further motivate the use of parse. Wdyt?

I prefer the string inputs and let the SDK validate it. It also is the approach for PayOnchainRequest / pay_onchain. Otherwise we have to start thinking about maybe changing send_payment to also take an InputType that is already parsed. Maybe it's a separate PR if it's agreed with @roeierez

[roeierez]

Leaving as string and validating sounds good to me. I agree with the documentation mentioning it should be a valid bitcoin address but not sure we should direct the user to validate it, it is better that we do it.

[danielgranhao]

Closed in favor of validating the input (#687)