Fix klay_getBlockWithConsensusInfo when receipts are unavailable

[hyunsooda]

Proposed changes

In cases where receipt data is not found in the database, it's important to check if the result of the receipt lookup is nil. Node operators may have deleted the receipt database to save disk space. In the event of an RPC serving panic, the node won't crash; instead, only an uninterpretable error message will be returned. This PR focuses on populating transaction data only when receipt data retrieval was unsuccessful.

> klay.getBlockWithConsensusInfo(klay.blockNumber - 10000000)
Error: method handler crashed
        at web3.js:6810:9(39)
        at send (web3.js:5221:62(29))
        at <eval>:1:31(6)

ERROR[12/18,03:46:32 Z] [39] RPC method klay_getBlockWithConsensusInfoByNumber crashed: runtime error: index out of range [0] with length 0
goroutine 3653 [running]:
github.com/klaytn/klaytn/networks/rpc.(*callback).call.func1()
        /home/ubuntu//bin/pr-2064/klaytn/networks/rpc/service.go:211 +0x85
panic({0x1cb2200?, 0xc0c73f45b8?})
        /usr/local/go/src/runtime/panic.go:914 +0x21f
github.com/klaytn/klaytn/consensus/istanbul/backend.(*APIExtension).makeRPCBlockOutput(0xc02c85f0c8, 0xc08ffae770, {{0xc1, 0x80, 0xca, 0x56, 0x5b, 0x34, 0xb5, 0xb6, ...}, ...}, ...)
        /home/ubuntu//bin/pr-2064/klaytn/consensus/istanbul/backend/api.go:321 +0x608
github.com/klaytn/klaytn/consensus/istanbul/backend.(*APIExtension).GetBlockWithConsensusInfoByNumber(0xc02c85f0c8, 0x47d253?)
        /home/ubuntu//bin/pr-2064/klaytn/consensus/istanbul/backend/api.go:379 +0x468
reflect.Value.call({0xc02ca1a060?, 0xc02ca1d490?, 0x7f1718ce5ef8?}, {0x1dd4028, 0x4}, {0xc0df57e4b0, 0x2, 0x4261d2?})
        /usr/local/go/src/reflect/value.go:596 +0xce7
reflect.Value.Call({0xc02ca1a060?, 0xc02ca1d490?, 0x1?}, {0xc0df57e4b0?, 0x1?, 0x16?})
        /usr/local/go/src/reflect/value.go:380 +0xb9
github.com/klaytn/klaytn/networks/rpc.(*callback).call(0xc02ca60480, {0x22c3e00?, 0xc0df57e410}, {0xc0df747020, 0x26}, {0xc0d64cd5a8, 0x1, 0xc02ca60480?})
        /home/ubuntu//bin/pr-2064/klaytn/networks/rpc/service.go:217 +0x37c
github.com/klaytn/klaytn/networks/rpc.(*handler).runMethod(0xc0df357270?, {0x22c3e00, 0xc0df57e410}, 0xc08ffae310, 0x1?, {0xc0d64cd5a8, 0x1, 0x1})
        /home/ubuntu//bin/pr-2064/klaytn/networks/rpc/handler.go:429 +0x55
github.com/klaytn/klaytn/networks/rpc.(*handler).handleCall(0xc02c48f000, 0xc0f6b383f0, 0xc08ffae310)
        /home/ubuntu//bin/pr-2064/klaytn/networks/rpc/handler.go:377 +0x21e
github.com/klaytn/klaytn/networks/rpc.(*handler).handleCallMsg(0x7f17a690b5b8?, 0x30?, 0xc08ffae310)
        /home/ubuntu//bin/pr-2064/klaytn/networks/rpc/handler.go:334 +0xbd
github.com/klaytn/klaytn/networks/rpc.(*handler).handleMsg.func2(0xc0f6b383f0)
        /home/ubuntu//bin/pr-2064/klaytn/networks/rpc/handler.go:166 +0x2f
github.com/klaytn/klaytn/networks/rpc.(*handler).startCallProc.func1()
        /home/ubuntu//bin/pr-2064/klaytn/networks/rpc/handler.go:256 +0xec
created by github.com/klaytn/klaytn/networks/rpc.(*handler).startCallProc in goroutine 1276
        /home/ubuntu//bin/pr-2064/klaytn/networks/rpc/handler.go:251 +0xb3

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...

[blukat29]

Maybe we can make it return transactions, not receipts.

Currently

• eth.getBlock(num, true) returns transactions
• klay.getBlock(num, true) returns transactions
• klay.getBlockWithConsensusInfo(num) returns receipts.

1. For consistency, klay.getBlockWithConsensusInfo(num) can return transactions.
2. Since we have eth.getBlockReceipts(num) and klay.getBlockReceipts(num) to return receipts, klay.getBlockWithConsensusInfo need not return receipts.

[hyunsooda]

@blukat29, is community notification required for this change? The Klaytn release informed that governance_getParams() is now replaced by governance_getItems() in the previous release.

[blukat29]

@hyunsooda Yes, I think changing the semantics is not trivial. I'm good with the current PR because it's minimal change.