Slatepack Workflow

[yeastplume]

Aims to implement the command-line workflow as specified in the Slatepack RFC.

As with all other slatepack-related PRs to date, note there's going to be a lot of extra code here to deal with backwards compatibility needed between release and HF3.

• Removes the method flag in favor of slatepack workflows
• dest is no longer mandatory for all functions that produce a slate. If provided, the slatepack sync-send workflow is invoked, followed by slatepack output if that fails. If not provided the slatepack is automatically output.
• if dest is provided as a slatepack address, slates are encrypted for the recipient.
• The sender field in the slate is filled out by default.
• All command-line functions that produce a slate for sending to the other party (init_send_tx, receive_tx, process_invoice_tx, etc) attempt to send via the slatepack's sender field if available, otherwise they revert to slatepack output.
• The OwnerAPI functions init_send_tx and process_invoice_tx will optionally invoke the slatepack sync workflow if the appropriate InitSendTx arguments are provided. The ForeignAPI function receive_tx will attempt to send if a return address is provided. This functionality is provided for convenience for upstream wallet developers. If these functions are used, the caller should check the slate's sta field to determine whether the sync send attempt succeeded, and invoke the slatepack workflow otherwise.
• All command-line functions that produce a slate output the slatepack to the terminal, as well as save the slatepack in a file [slatepack/[slate-id].[slate.state].slatepack.
• The input argument for all command-line functions that accept a slate is no longer mandatory. If included, the function will attempt to read from the given file. If not, the function will prompt the user to paste slatepack data into the terminal directly.
• TOR send is fixed via a custom version of the hyper-socks2 crate
• Adds an http(s) deprecation warning and nag prompt when the provided send address begins with 'http'

[yeastplume]

Ready for merge, top comment is updated with details of changes.

[quentinlesceller]

Currently reviewing the code but out of curiosity a send from this version to a v3.1.1 node through Tor fails. Is it expected?

[yeastplume]

No, but there are now dozens of permutations of sends and receives that need to be tested, particularly between wallet versions. There are definitely issues that will need to be worked through over the beta period

[j01tz]

Reviewed to verify the slatepack workflow logic: this PR accurately captures the workflow of the specification.

minor note: it looks like keybase method is essentially removed, we should probably make sure this is explicit in release notes just in case anyone is relying on it.

Really looking forward to testing and refining further. Great work putting this all together so fast, inspiring!