fix: thorchain swap improvements

[kaladinlight]

Description

• Use 0 limit for thorchain streaming swaps which will use TC auto stream limits which should result in more completed trades and less refunds (see: https://discord.com/channels/838986635756044328/1166265575941619742/1166500062101250100)
  • Because we are using auto limits, don't show Min expected after slippage as we can't determine this accurately
  • TODO: disable custom slippage limit for streaming swaps in the UI (no being used, so want to make sure the user doesn't think they are using something they aren't) @reallybeard let me know if you have a good idea on how to handle this or if we even need to address specifically since we aren't showing the slippage details in the summary
• Calculate trade slippage on expected_amount_out and don't account for affiliate fees in these calculations and display values as they are shown elsewhere (this very closely reflects TS UI as changed)

Pull Request Type

• 🐛 Bug fix (Non-breaking Change: Fixes an issue)
• 🛠️ Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
• 💅 New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #5733

Risk

Medium - this changes our limit logic on both regular and streaming swaps, we will want to do our best to verify completed trades and also monitor after this update is deployed to ensure we have reduced the occurrences of refunds for all thor trades

Testing

• Ensure regular TC trades succeed and validate trade values against TS for sanity check (should see limit set in the memo)
• Ensure streaming TC trades succeed and validate trade values against TS for sanity check (should see 0/10/0 streaming params in the memo, the first zero being limit = auto limit)

Engineering

☝️

Operations

☝️

Screenshots (if applicable)

No affiliate fee

SS	TS

"=:ETH.DAI-0X6B175474E89094C44DA98B954EEDEAC495271D0F:0x7ae920bef29c849415635b1b97f1ceb33dca89b6:0/10/0:ss:30"
"=:ETH.DAI:0x7ae920bEf29c849415635B1b97f1CeB33dca89B6:0/3/6:t:30"
"=:ETH.DAI-0X6B175474E89094C44DA98B954EEDEAC495271D0F:0x7ae920bef29c849415635b1b97f1ceb33dca89b6:116914475388:ss:30"
"=:ETH.DAI:0x7ae920bEf29c849415635B1b97f1CeB33dca89B6:117015146861:t:30"

[gomesalexandre]

Conceptual stamp, haven't tested this at runtime yet but this is exactly what I thought the PR would look like 🏆 looks sane to me and on par with THORSwap for streaming swaps

[0xApotheosis]

Functional test, memo looking as expected for streaming swaps:

0XC770EEFAD204B5180DF6A14EE197D99D808EE52D:0xB0E5C1DD13D78a314c3c0d82CE2C9f4c65C3e02c:0/10/0:ss:30.

[0xApotheosis]

@kaladinlight I'll hold off on merging, as I'm not sure is you wanted to address the "TODO: disable custom slippage limit" in this PR, or a follow-up.

[gomesalexandre]

Sanity tested with frame-injected vitalik.eth against THORSwap:

• Receive amounts look sane against THORSwap

• Memo looks sane against TS:

• Limit is indeed present for streaming swaps
• We use 0/10/0 as streaming parameters as mentioned in the testing steps. i.e:
  • 0 is on par with the explicit quantity from TS (0/explicit quantity from quote is the same), and
  • 10 is valid as per our current heuristics, possibly too high, but our 1/5/10 interval heuristics won't hurt, only make swaps possibly longer vs. the 3 used by TS for a similar a swap