Slatepack OwnerAPI Changes

[yeastplume]

This PR aims to:

• Expose Slatepack changes via the OwnerAPI
• Ensure all user-facing instance of addresses in the API use a SlatepackAddress. This means that what was previously either being input/output by the user as a payment proof address or TOR address will now be a Slatepack address.

In detail:

• Change the get_public_proof_address Owner API function to get_slatepack_address and return a slatepack address instead.
• Remove the proof_address_from_onionv3 function from the Owner API as it's no longer needed
• As a result of above changes, arguments to init_send_tx and other places become a slatepack address.
• Add a new Owner API functions to output a slate as a Slatepack

New API functions are:

• create_slatepack_message - returns an (optionally encrypted) armored slatepack string from a slate
• slate_from_slatepack_message - extracts the slate from the given slatepack string, attempting to decrypt from a range of deriviation indices if necessary (takes a vec instead of a single value for future multiple-address use)
• decode_slatepack_message - convenience function that returns the Slatepack struct itself, which can be viewed as json.

Notes:

• The command line might be a bit broken as of this PR, which is fine and will be addressed in the next PR which will implement the command-line slatepack workflow.
• Internally, addresses are still stored in the tx log and appear in the slate as ed25519 keys, for backwards compatibility.

[yeastplume]

Updated top comment, should be ready for review

[j01tz]

Reviewed for general slatepack logic in OwnerAPI, a few non-critical notes:

• is it worth splitting out get_slatepack_secret_edkey() and get_slatepack_secret_xkey() in the API in case someone wants to do encryption/decryption at a different layer? or is that too much complexity/opportunity for confusion in the API calls for the convenience?

• before beta we will want to add stricter validation for anything exposed in libwallet

This is coming together nicely, can't wait to start hitting the command-line workflow.

I hope some others are watching this to see beastplume in action

[yeastplume]

Reviewed for general slatepack logic in OwnerAPI, a few non-critical notes:

• is it worth splitting out get_slatepack_secret_edkey() and get_slatepack_secret_xkey() in the API in case someone wants to do encryption/decryption at a different layer? or is that too much complexity/opportunity for confusion in the API calls for the convenience?

This can be added at any time if anyone calls for it, but might as well keep it simple for the moment.