Path payment api is awkward for general currency conversion

[vcarl]

The existing API of recipient address, sender address, recipient asset, and recipient amount works very well when seeking paths that ensure a specified payment will be received at the end. However, we're trying to provide a UI for converting asset A into asset B as part of our SEP-6 withdrawal flow, and this API isn't a good fit for the use case. We're constrained by:

• the amount being sent (instead of how much should be received)
• what asset is being sent
• what asset is received
• we don't know who the recipient is at this stage

This seems to me like a common alternative to a path payment—a path conversion if you will, analogous to changing all the cash in your wallet when you arrive in a new country. The UI we imagine is a list of all (e.g.) BTC tokens you hold and how much you'd receive from a SEP-6 anchor after converting them.

It seems like we should be able to work around this without any changes, but I wanted to surface it as a pain point we encountered.

[tomquisel]

Transferring to stellar-protocol, as this will require a protocol change to address.

[tomquisel]

CAP-24 proposes a new kind of path payment that takes a fixed amount to send and maximizes the amount of destination asset received (the mirror of existing path payment). It addresses this issue, and it ensures that the full send amount that the caller requires is consumed.

[tomquisel]

@morleyzhi I just wanted to check that you think the CAP-24 solution meets Vega's needs.

To summarize the new path payment's semantics:

If PathPaymentStrictSendOp succeeds then the source account is debited exactly sendAmount of sendAsset and the destAccount is credited at least destMin of destAsset.

Let me know if that sounds good!

@theaeolianmachine @jonjove

[jonjove]

Implemented in stellar/stellar-core#2269