Remove KIR/PoC and introduce KCF/KFF from API returns and internal code

[aidan-kwon]

Proposed changes

This PR is a part of KGP-6 implementation, however, it causes a change in the API return format.

1. The change in RewardSpec affects to klay_getRewards API
   Before

{
        "minted": 6400000000000000000,
        "totalFee": 70825700000000000,
        "burntFee": 35412850000000000,
        "proposer": 3217706425000000000,
        "stakers": 0,
        "kgf": 2574165140000000000,
        "kir": 643541285000000000,
        "rewards": {
            "0x179679457f93094a4e7186abcb2089661e92fc22": 3217706425000000000,
            "0x278e6332d69eed782784d21802e3504a64a16456": 2574165140000000000,
            "0x3d803a7375a8ee5996f52a8d6725637a89f5bbf8": 643541285000000000
        }

After

{
        "minted": 6400000000000000000,
        "totalFee": 70825700000000000,
        "burntFee": 35412850000000000,
        "proposer": 3217706425000000000,
        "stakers": 0,
        "kff": 2574165140000000000,
        "kcf": 643541285000000000,
        "rewards": {
            "0x179679457f93094a4e7186abcb2089661e92fc22": 3217706425000000000,
            "0x278e6332d69eed782784d21802e3504a64a16456": 2574165140000000000,
            "0x3d803a7375a8ee5996f52a8d6725637a89f5bbf8": 643541285000000000
        }

2. The change in StakingInfo struct affects to klay_getStakingInfo API.
   This change also affects to StakingInfo data stored in database, so the unmarshal function of StakingInfo is added to support both legacy data and new data.

Before

{
        "BlockNum": 115171200,
        "CouncilNodeAddrs": [ ... ... ],
        "CouncilStakingAddrs": [ ... ... ],
        "CouncilRewardAddrs": [ ... ... ],
        "KIRAddr": "0x3d803a7375a8ee5996f52a8d6725637a89f5bbf8",
        "PoCAddr": "0x278e6332d69eed782784d21802e3504a64a16456",
        "UseGini": true,
        "Gini": 0.61,
        "CouncilStakingAmounts": [ ... ... ]
    }

After

{
        "blockNum": 115171200,
        "councilNodeAddrs":  [ ... ... ],
        "councilStakingAddrs":  [ ... ... ],
        "councilRewardAddrs":  [ ... ... ],
        "kcfAddr": "0x3d803a7375a8ee5996f52a8d6725637a89f5bbf8",
        "kffAddr": "0x278e6332d69eed782784d21802e3504a64a16456",
        "useGini": true,
        "gini": 0.61,
        "councilStakingAmounts":  [ ... ... ],
    }

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

[kjeom]

No need to add hard fork logic?

[blukat29]

chaindata/misc produced by this version may break old nodes. Do we need an intermediate period where both names are stored in the database?

[aidan-kwon]

No need to add hard fork logic?

This change affects to only two APIs that is not widely used. So, I just make a change and announce it by publishing an interface KIP.

[aidan-kwon]

chaindata/misc produced by this version may break old nodes. Do we need an intermediate period where both names are stored in the database?

I introduced a JSON marshal method to provide backward compatibility

[aidan-kwon]

@ethan-kr @ian0371 @blukat29 PTAL