Add node configuration status to node stats

[Linicks]

Basic Description: It would be very valuable for pool operators to have the current node operating configuration in the node stats output. When operating a number of nodes, and building management tooling around it, having the ability to see if the node is acting as a passive node or slot leader would reduce errors, and ease management.

Describe the solution you'd like When executing the stats get request, return the configuration state of the node.

jcli rest v0 node stats get --host "http://127.0.0.1:3100/api" --output-format json { "blockRecvCnt": 956, "lastBlockContentSize": 315, "lastBlockDate": "17.12606", "lastBlockFees": 800000, "lastBlockHash": "9963f2908cd61e41debc47e7d7cbb3a963a572dcc27bb64ff172fa6ad6b0e614", "lastBlockHeight": "56849", "lastBlockSum": 4736427743, "lastBlockTime": "2019-12-31T02:13:49+00:00", "lastBlockTx": 1, "lastReceivedBlockTime": "2019-12-31T02:13:49+00:00", "state": "Running", "txRecvCnt": 465, "uptime": 11127, "configuration":"slot_leader" ---- OR ---------- "configuration":"passive_node" "version": "jormungandr 0.8.5-3db0680" }

[rdlrt]

You could simply use the below instead:

jcli rest v0 leaders get

"configuration": "slot_leader" is vague, other than the nomen clature - you could have multiple leaders from one node, which is easily identified by the above command instead.

[Linicks]

I'm currently using the results from : jcli rest v0 leaders get, but it doesn't meet the objectives that I intended for this feature request. The node stats are one of, if not the primary metric that pool operators utilize to see the state of their pool in one glance. By adding the configuration status or equivalent to the stats, the operator would know instantly if the node itself is configured and running as a slot leader. In this case the slot leader id's aren't as relevant because the desired metric is more Boolean in nature. However, you could return the id's rather than a generic string. The other issue with using two endpoints to check the state of the node is that you're performing two requests and processing both, rather than just getting the node stats and parsing a single request. Having one get would make for easier tooling development, and reduce operator errors.