Problem: tx delivery performance is not benchmarked

[yihuang]

Solution:

• add the first benchmark for tx delivery (typical erc20 transfers)

Test Results

$ go test -run=^$ -bench=BenchmarkERC20Transfer -benchmem ./app
goos: darwin
goarch: amd64
pkg: github.com/crypto-org-chain/cronos/v2/app
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkERC20Transfer/memdb-12         	       1	1316400164 ns/op	277784600 B/op	 4731271 allocs/op
BenchmarkERC20Transfer/leveldb-12       	       1	1385148085 ns/op	278984336 B/op	 4729347 allocs/op
PASS
ok  	github.com/crypto-org-chain/cronos/v2/app	5.249s

• it takes around 1.3s to execute a block with 1000 erc20 transfer txs
• profile shows ante handler spend a little bit more than msg execution
• goleveldb result is very close to memdb.
• ethereum sender recovery is a hotspot, another one seems to be GetParams.

👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻

PR Checklist:

• Have you read the CONTRIBUTING.md?
• Does your PR follow the C4 patch requirements?
• Have you rebased your work on top of the latest master?
• Have you checked your code compiles? (make)
• Have you included tests for any non-trivial functionality?
• Have you checked your code passes the unit tests? (make test)
• Have you checked your code formatting is correct? (go fmt)
• Have you checked your basic code style is fine? (golangci-lint run)
• If you added any dependencies, have you checked they do not contain any known vulnerabilities? (go list -json -m all | nancy sleuth)
• If your changes affect the client infrastructure, have you run the integration test?
• If your changes affect public APIs, does your PR follow the C4 evolution of public contracts?
• If your code changes public APIs, have you incremented the crate version numbers and documented your changes in the CHANGELOG.md?
• If you are contributing for the first time, please read the agreement in CONTRIBUTING.md now and add a comment to this pull request stating that your PR is in accordance with the Developer's Certificate of Origin.

Thank you for your code, it's appreciated! :)

[mmsqe]

runMsgs seems heavier than ante handles

[yihuang]

runMsgs seems heavier than ante handles

that's allocation?

[mmsqe]

runMsgs seems heavier than ante handles

that's allocation?

yes, and cpuprofile shows

[yihuang]

runMsgs seems heavier than ante handles

that's allocation?

yes, and cpuprofile shows

ok, they are close enough, the result is not exactly the same in different runs