[PAN-2927] Add documentation for getSignerMetrics

[matkt]

PR description

Add documentation for the new clique_getSignerMetrics and ibft_getSignerMetrics JSON-RPC methods.

[MadelineMurray]

With ibft_getSignerMetrics, I'm getting a proposed block from address 0x000000000000 in the results which I'm assuming shouldn't be there?

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": [
        {
            "address": "0x120f5d5df0fbe9f85b566c3cf7ed2749f496d49b",
            "proposedBlockCount": "0x3",
            "lastProposedBlockNumber": "0x3"
        },
        {
            "address": "0x0000000000000000000000000000000000000000",
            "proposedBlockCount": "0x1",
            "lastProposedBlockNumber": "0x0"
        }
    ]
}

[matkt]

With ibft_getSignerMetrics, I'm getting a proposed block from address 0x000000000000 in the results which I'm assuming shouldn't be there?

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": [
        {
            "address": "0x120f5d5df0fbe9f85b566c3cf7ed2749f496d49b",
            "proposedBlockCount": "0x3",
            "lastProposedBlockNumber": "0x3"
        },
        {
            "address": "0x0000000000000000000000000000000000000000",
            "proposedBlockCount": "0x1",
            "lastProposedBlockNumber": "0x0"
        }
    ]
}

for me it is the address 0x000000000000 which is the proposer of block 0. I do not see any particular error. I will check

[ajsutton]

This is an interesting little corner case - technically the genesis block doesn't have a proposer, it just always existed since the dawn of the chain. That gets very confusing though so we tend to treat it as 0x0... is the proposer which is why it's showing up here. I'm guessing your chain is less than 200 blocks long so the genesis block is being included in the report.

I think this result is pretty reasonable - the only other thing we could do is exclude the genesis block from this report entirely. That would also be reasonable but have the odd corner case of reporting nothing if you ask for only the genesis block or if you haven't yet sync'd any blocks.

Maybe just add a note to explain that the genesis block's proposer is reported as 0x0...?

[matkt]

This is an interesting little corner case - technically the genesis block doesn't have a proposer, it just always existed since the dawn of the chain. That gets very confusing though so we tend to treat it as 0x0... is the proposer which is why it's showing up here. I'm guessing your chain is less than 200 blocks long so the genesis block is being included in the report.

I think this result is pretty reasonable - the only other thing we could do is exclude the genesis block from this report entirely. That would also be reasonable but have the odd corner case of reporting nothing if you ask for only the genesis block or if you haven't yet sync'd any blocks.

Maybe just add a note to explain that the genesis block's proposer is reported as 0x0...?

I think it is a good way to fix the issue. @MadelineMurray

[matkt]

With ibft_getSignerMetrics, I'm getting a proposed block from address 0x000000000000 in the results which I'm assuming shouldn't be there?

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": [
        {
            "address": "0x120f5d5df0fbe9f85b566c3cf7ed2749f496d49b",
            "proposedBlockCount": "0x3",
            "lastProposedBlockNumber": "0x3"
        },
        {
            "address": "0x0000000000000000000000000000000000000000",
            "proposedBlockCount": "0x1",
            "lastProposedBlockNumber": "0x0"
        }
    ]
}

I just added a note for the genesis block

[MadelineMurray]

Pushed some edits. Thanks for your contribution and sorry about the delay in reviews!