`zetacored` : Improve outbound tracker cleanup

[kingpinXD]

Outbound trackers are not cleaned up correctly according to the present logic.

Reasons

• We delete the tracker associated with the current outbound, but in situations where a revert is added, this would skip deleting the original tracker connected to outparams[0].

https://github.com/zeta-chain/zeta-node/blob/3b1861011e123bbd9aba86210d104e50d1c0f70d/x/crosschain/keeper/msg_server_vote_outbound_tx.go#L199-L201

• zeta clients can sometimes create trackers that are not required. These trackers get added if the CCTX is not in a terminal state, such as PendingRevert, which does not match this condition .

https://github.com/zeta-chain/zeta-node/blob/update-connectors/x/crosschain/keeper/msg_server_add_outbound_tracker.go#L52-L52

Proposed Fixes

• We can remove all trackers associated with an outbound when finalized. If len(cctx.OutboundParams) >1, we can try deleting both trackers.

• The tracker index chainID-Nonce is not unique to multiple TSS keys. To be safe, we can migrate the index to tssPubkey-chainID-Nonce and use Pubkey+ChainID to fetch pending trackers on the client. This is more of an added precaution as we expect the trackers to be cleaned up before a TSS migration, but it would still be good to have

### Tasks
- [ ] https://github.com/zeta-chain/node/issues/2610
- [ ] https://github.com/zeta-chain/node/issues/2664

[lumtis]

The tracker index chainID-Nonce is not unique to multiple TSS keys. To be safe, we can migrate the index to tssPubkey-chainID-Nonce and use Pubkey+ChainID to fetch pending trackers on the client. This is more of an added precaution as we expect the trackers to be cleaned up before a TSS migration, but it would still be good to have

Is it related to the problem described above? In which sense?

Can't we just add the TSS Pubkey in the tracker object instead of updating the indexation? Also chainID-tssPubkey-Nonce would be more appropriate as it would be better to keep the ability to list all trackers per chains

[kingpinXD]

The chainId-nonce key is not unique for two generated TSS keys. To make that happen, we would need to add the subkey to the index.

1. The first fix ensures that no trackers are left at the end of a CCTX lifecycle, which should solve most problems. We would not expect to have any trackers left over.

2. However, in the off-chance that there are some trackers left over ( trackers already existing before this fix fix is deployed, for example ), the second fix will make sure they are not pickup up after migration as the zetaclient will be able to query using ChainID+TSSPubkey

With that said, the first fix should be enough for me to finish working on the TSS migration tests. I can create a issue for the second and work on that after the Solana work is done , as it touches both zetacore and zetaclient , and might need a migration script