feat: custom priority mempool

[skosito]

Description

In cosmos 0.47, application mempools are possible https://docs.cosmos.network/main/build/building-apps/app-mempool
There are 2 provided implementation, sender nonce and priority nonce mempools. Priority nonce seems like it's most suitable for this usecase - give more priority to system txs.

Mempools from cosmos 0.47 assume signatures can be extracted from sdk.Tx, but it doesn't work for ethermint txs. On latest cosmos-sdk main branch, signer extractor adapter is present, which can be used to provide custom adapter to pull out senders and nonces (check cronos ethermint for example).
But, on 0.47 this option is not present, so I forked priority nonce mempool, and default proposal handler, and only replaced part with that custom signer adapter.

Tests will be added in:
#2182
#2183

Closes: #734

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

[lumtis]

Nice.

Any way it has been tested? I may think we could maybe introduce a new local env setup where the max gas per block is low and we send many txs, checking if system txs pass through.
This can be a general setup for stress tests, we currently have a stress tests command but it will need to be improved

[github-actions]

!!!WARNING!!!
nosec detected in the following files: app/custom_proposal_handler.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.

[skosito]

@lumtis thanks for review, fixed the comments

regarding testing, i think for unit tests we can also fork them and add ethermint handling if possible in this PR, will do that here

regarding e2e and stress tests, maybe we can discuss proper setup and handle in follow up PR?

[lumtis]

@lumtis thanks for review, fixed the comments
regarding testing, i think for unit tests we can also fork them and add ethermint handling if possible in this PR, will do that here
regarding e2e and stress tests, maybe we can discuss proper setup and handle in follow up PR?

Sounds good to me, do we already have a follow up issue?

[skosito]

@lumtis thanks for review, fixed the comments
regarding testing, i think for unit tests we can also fork them and add ethermint handling if possible in this PR, will do that here
regarding e2e and stress tests, maybe we can discuss proper setup and handle in follow up PR?

Sounds good to me, do we already have a follow up issue?

Yes, added 2 issues for these missing pieces since they are a bit more involved will handle in separate PRs, and will merge this one. Issues are:

#2182
#2183

[gartnera]

stamp