services/horizon: Add Muxed Account details to operation responses

[2opremio]

Part of #3591

It follows the design discussed at #3591

It abuses the operation details to encode source_account_muxed and source_account_muxed_id

TODO:

• Add tests

[tomerweller]

I don't think trustor can be muxed: https://github.com/stellar/stellar-core/blob/b9e10051eafa1125e8d238a47e5915dad30c2640/src/xdr/Stellar-transaction.x#L241

Not all accounts can be muxed. I would double check against the xdr definitions. MuxedAccount can be muxed, AccountID can not.

[ire-and-curses]

Yes - I itemised these in this issue for reference @2opremio : #3490

[ire-and-curses]

One complication: M addresses are not fully interchangeable with G. If you grep for AccountID in Stellar-transaction.x, you'll see the places where AccountID was preserved. These are: CreateAccount, SetOptions, AllowTrust, and SponsoringFutureReserves, as well as various operation results. The parsing implementation should disallow such invalid address uses.

[leighmcculloch]

I find it helpful to look at where we need to add support, which is everywhere MuxedAccount is used.

/workspaces/stellar-core $ git grep -p -n MuxedAccount -- src/xdr/
src/xdr/Stellar-transaction.x=7=namespace stellar
src/xdr/Stellar-transaction.x:11:union MuxedAccount switch (CryptoKeyType type)
src/xdr/Stellar-transaction.x=77=struct PaymentOp
src/xdr/Stellar-transaction.x:79:    MuxedAccount destination; // recipient of the payment
src/xdr/Stellar-transaction.x=95=struct PathPaymentStrictReceiveOp
src/xdr/Stellar-transaction.x:102:    MuxedAccount destination; // recipient of the payment
src/xdr/Stellar-transaction.x=120=struct PathPaymentStrictSendOp
src/xdr/Stellar-transaction.x:125:    MuxedAccount destination; // recipient of the payment
src/xdr/Stellar-transaction.x=376=struct ClawbackOp
src/xdr/Stellar-transaction.x:379:    MuxedAccount from;
src/xdr/Stellar-transaction.x=413=struct Operation
src/xdr/Stellar-transaction.x:418:    MuxedAccount* sourceAccount;
src/xdr/Stellar-transaction.x:439:        MuxedAccount destination;
src/xdr/Stellar-transaction.x=472=case ENVELOPE_TYPE_OP_ID:
src/xdr/Stellar-transaction.x:475:        MuxedAccount sourceAccount;
src/xdr/Stellar-transaction.x=550=struct Transaction
src/xdr/Stellar-transaction.x:553:    MuxedAccount sourceAccount;
src/xdr/Stellar-transaction.x=585=struct FeeBumpTransaction
src/xdr/Stellar-transaction.x:587:    MuxedAccount feeSource;

So, based on that, I see these places as the only places we should be expecting it:

• FeeBumpTransaction feeSource
• Transaction sourceAccount
• Operation sourceAccount
• PaymentOp destination
• PaymentPaymentStrictReceiveOp destination
• PathPaymentStrictSendOp destination
• ClawbackOp from
• AccountMergeOp (there's not actually a type for this in the XDR) destination

[2opremio]

@leighmcculloch there are some derived fields in operations which are also muxed

Also, note that this PR is specific about operations

[2opremio]

I don't think trustor can be muxed

Note that we use the operation source as trustor: https://github.com/stellar/go/pull/3603/files#diff-5f37fbbec67583bbaa94cbe645d8a4aa046505cee2c37be660818ef340645ab1L346-R355 and the source is muxed

My criteria to mark something as muxed or not was whether what we use when populating the operation details is muxed or not (see the changes in operations_processor.go)