feat: state data for aborted tx amount

[kingpinXD]

Description

• Adds new state data to track the total amount of zeta tokens that have been aborted
• This value is accounted for the zeta supply checker

Closes:

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Include instructions and any relevant details so others can reproduce.

• Tested CCTX in localnet
• Tested in development environment
• Go unit tests
• Go integration tests
• Tested via GitHub Actions

Checklist:

• I have added unit tests that prove my fix feature works

[github-actions]

!!!WARNING!!!
nosec detected in the following files: x/crosschain/keeper/grpc_query_cctx.go, x/crosschain/keeper/keeper_cross_chain_tx.go, x/crosschain/types/keys.go

Be very careful about using #nosec in code. It can be a quick way to suppress security warnings and move forward with development, it should be employed with caution. Suppressing warnings with #nosec can hide potentially serious vulnerabilities. Only use #nosec when you're absolutely certain that the security issue is either a false positive or has been mitigated in another way.

Only suppress a single rule (or a specific set of rules) within a section of code, while continuing to scan for other problems. To do this, you can list the rule(s) to be suppressed within the #nosec annotation, e.g: /* #nosec G401 */ or //#nosec G201 G202 G203
Broad #nosec annotations should be avoided, as they can hide other vulnerabilities. The CI will block you from merging this PR until you remove #nosec annotations that do not target specific rules.

Pay extra attention to the way #nosec is being used in the files listed above.

[lumtis]

It looks good to me.
I'm just wondering, for future-proofing purposes, maybe we could use a more general state variable ZetaAccounting instead AbortedZetaAmount and add abortedAmount in this state variable. It would reduce complexity and refactoring work in case we want to add a new variable for accounting purpose in the store in the future.
What do you think?

[brewmaster012]

1. The function name AddZetaAccounting can be more specific.
2. Do you need to test whether the outbound is supposed to be ZETA token transfer, not some other tokens?

[kingpinXD]

Thanks , good catch !

[kevinssgh]

Just a typo in a file name: x/crosschain/keeper/zeta_accountin.go