Fix reward distribution and getRewards API on deferredTxfee = false

[JayChoi1736]

Proposed changes

Problems
Reward distribution has problems from the first version of Klaytn code when deferredTxfee = false

1. total transaction fee goes to block proposer(in ApplyTransactions), instead of rewardbase
   - condition : all
2. gasPrice value for total reward calculation is not set properly. gasPrice from userInput was used, instead of gasPrice in header(in ApplyTransactions)
   - condition : after Magma hardfork
3. total transaction fee is added to block proposer(in ApplyTransactions) and rewardbase(in Block.Finalize) duplicatively. Additionally, magma hardfork content(halft of fee burn) was applied only to totaltxfee in block.finalize process
   - condition : policy = simple = 0, before Kore Hardfork

Solutions

1. total transaction fee goes to rewardBase in ApplyTransaction. For this, I have to put rewardbase in evm context. Please let me know if you find any issues with this or if you know of a better way.
2. gasPrice value is now properly set after Magma Hardfork. I've checked servicechains, and they didn't proceed Magma hardfork.( I checked MBX and cocone, but still waiting for reply for bora servicechain)
3. now total transaction fee only goes to rewardbase, from after Magma Hardfork( same reason as 2. )
4. Now half of txfee is burnt after Magma hardfork
5. Now half of txfee is burnt also after Kore hardfork and not proceed additional burn which is defined in KIP82. This is the same logic when DeferredTxfee = true, policy = simple.

Additional
I found problems with testcases in test/ folder, which uses GenABlockWithTransactions, GenABlockWithTxPool

• this is the function which compares accountmaps' balance in mock environment and stateDB's balance after insertChain
• they uses deferredTxfee = false environment
• gasUsed in mock environment was wrong, but the problems didn't revealed because deferredTxfee=false, and tx sender = rewardBase in testcases
• I deactivated one testcase first, and will fix every testcases with next PR

Types of changes

Please put an x in the boxes related to your change.

• Bugfix
• New feature or enhancement
• Others

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING GUIDELINES doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes ($ make test)
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Related issues

• Please leave the issue numbers or links related to this PR here.

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[aidan-kwon]

You will change back to the original code after fixing all related bug, right? Can you just comment out and add TODO tag for this?

[JayChoi1736]

resolved by e24351e