Feat: Boost Support for Vault Swaps

[msgmaxim]

Pull Request

Closes: PRO-1753

Summary

• Added additional fields to vault_swap_request (height, deposit_address, channel_id). This is needed for DepositBoosted/DepositFinalised events. I also made it take a vec of deposits (represented as VaultDepositWitness) instead to be consistent with "regular" deposits and as a better (compared to box-ing individual fields) solution to the "max call size" problem that occurs when we have too many paramters not on a heap. Right now engines still vote on individual deposits (i.e. vec of size 1), but we can change this in the future and submit batches of deposits like we do for regular deposits (@dandanlen mentions that this might require some discussion, so not done here).

• Added BoostedVaultTxs field to track the status of vault deposits (regular deposits use DepositChannelLookup for this)

• Added DepositOrigin which mimicks SwapOrigin but excludes Internal variant and makes more sense in contexts where we are not necessarily dealing with swaps, but deposits in general. I considered merging them into one to simplify, but seemed a bit cleaner to have explicit types (but happy to reconsider).

• Factored out process_prewitness_deposit_inner and process_full_witness_deposit_inner so that the core logic is used regardless of the "origin". Deposit extrinsics now just assemble the parameters for the channel action, perform validation where needed, and read/update the boost status.

• DepositBoosted/DepositFinalised events now include DepositOriginType so the product knows whether channel_id should be used to lookup deposit channel details for example. @niklasnatter

Edit: I might need to check unit-tests/bouncer tests to see why they fail, but otherwise this PR should be read for review.

[msgmaxim]

I think a cleaner solution for extracting/passing source_address might be to create a different struct e.g. DepositAction which will include CcmDepositMetadata instead of CcmChannelMetadata in ChannelAction (and/or making ChannelAction generic over metadata, though this would make the code less readable), but I chose to go with a solution that requires fewer code changes for now.

[codecov]

Codecov Report

Attention: Patch coverage is 87.68529% with 108 lines in your changes missing coverage. Please review.

Project coverage is 72%. Comparing base (d12200a) to head (573982a).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
state-chain/pallets/cf-ingress-egress/src/lib.rs	93%	29 Missing and 2 partials ⚠️
...te-chain/runtime/src/chainflip/solana_elections.rs	0%	19 Missing ⚠️
engine/src/witness/arb.rs	0%	13 Missing ⚠️
engine/src/witness/btc/deposits.rs	0%	13 Missing ⚠️
engine/src/witness/eth.rs	0%	12 Missing ⚠️
engine/src/witness/evm/vault.rs	0%	7 Missing ⚠️
state-chain/traits/src/mocks/balance_api.rs	25%	6 Missing ⚠️
state-chain/pallets/cf-lp/src/mock.rs	67%	3 Missing ⚠️
...ate-chain/pallets/cf-ingress-egress/src/weights.rs	0%	2 Missing ⚠️
state-chain/chains/src/lib.rs	80%	0 Missing and 1 partial ⚠️
... and 1 more

Additional details and impacted files

@@          Coverage Diff           @@
##            main   #5437    +/-   ##
======================================
  Coverage     72%     72%            
======================================
  Files        494     494            
  Lines      87751   87926   +175     
  Branches   87751   87926   +175     
======================================
+ Hits       62826   62982   +156     
- Misses     22310   22365    +55     
+ Partials    2615    2579    -36     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[albert-llimos]

channel_id is not needed and actually makes no sense outside of Bitcoin, as the premise of Vault swaps is to not need a channel. Therefore passing a channel_id as a mandatory parameter to vault_swap_request and arbitrarily hardcoding that to zero for other chains seems misleading to me. It could even be just wrong for chains were channels are reused as we could currently be using that channel.
I'd suggest making that an Option. EDIT: Or if we can fit it into DepositDetails or some other parameter that could make sense.

[kylezs]

pretty minor comments overall 👌