RPC: add 'getpeerinfo', returning easy-to-retrieve per-CNode data #1531

This pull request adds 'getpeerinfo', initially returning low-hanging fruit available inside each CNode.

Once this initial form is OK'd, additional commits will add per-message statistics similar to those seen in now-closed req #1510.

Example output:

     [
     {
        "addr" : "64.27.57.122:8333",
        "services" : "1",
        "last_send" : "1340943593",
        "last_send_empty" : "1340943593",
        "last_recv" : "1340943593",
        "time_conn" : "1340943569",
        "version" : 60001,
        "subver" : "/Satoshi:0.6.3/",
        "inbound" : false,
        "time_release" : "0",
        "start_height" : 186712,
        "banscore" : 0
     },
     {
        "addr" : "178.152.104.61:8333",
        "services" : "1",
        "last_send" : "1340943593",
        "last_send_empty" : "1340943593",
        "last_recv" : "1340943592",
        "time_conn" : "1340943591",
        "version" : 40000,
        "subver" : "",
        "inbound" : false,
        "time_release" : "0",
        "start_height" : 186712,
        "banscore" : 0
     }
     ]

1. Shouldn't it be protocol_version and user_agent now?
2. What's with string times/bitfields?

As with #1510, the int64 fields are rendered as strings to avoid known big-int-handling bugs in the field.

I like it— should the start time be an absolute time or an uptime?

I don't like the int64 fields as strings; we already output time (int64) fields as Numbers in other parts of the RPC interface. If JSON libraries can't handle them, then the JSON libraries need to be fixed.

Updated commit with new output:

[
    {
        "addr" : "94.198.135.29:8333",
        "services" : "1",
        "last_send" : 1340997595,
        "last_send_empty" : 1340997598,
        "last_recv" : 1340997584,
        "time_conn" : 1340997577,
        "version" : 60001,
        "subver" : "/Satoshi:0.6.3/",
        "inbound" : false,
        "time_release" : 0,
        "start_height" : 186795,
        "banscore" : 0
    },
    {
        "addr" : "193.238.41.117:8333",
        "services" : "1",
        "last_send" : 1340997592,
        "last_send_empty" : 1340997598,
        "last_recv" : 1340997595,
        "time_conn" : 1340997590,
        "version" : 60001,
        "subver" : "/Satoshi:0.6.2/",
        "inbound" : false,
        "time_release" : 0,
        "start_height" : 186795,
        "banscore" : 0
    }
]

Note that "services" is a hex string, and remains quoted.

All the other hex-encoded strings are fixed-width (zero padded).

For versions, it seems better to show:

        "protocol_version" : 60001,
        "user_agent" : [{"Satoshi": "0.6.2"}, ...],

I think last_send_empty is not a very clear name. Maybe "last attempted send" ?

Not sure if it's a useful statistic in general, it's only useful to debug the network event loop code, imho.

Overall ACK, nit-picking: "01" for services would make it more obviously hex-encoded (I agree hex-encoded is right for services).

naming convention for stuff output from RPC calls is wordsmushedtogether, not words_separated_by_underscores. And footime, not timefoo (I'm looking at the output of 'grep Pair bitcoinrpc.cpp' to see all the stuff output).

Updated commit; new output:

[
    {
        "addr" : "46.147.8.78:8333",
        "services" : "00000001",
        "lastsend" : 1341005008,
        "lastrecv" : 1341005008,
        "conntime" : 1341004942,
        "version" : 40000,
        "subver" : "",
        "inbound" : false,
        "releasetime" : 0,
        "height" : 186813,
        "banscore" : 0
    },
    {
        "addr" : "71.42.11.79:8333",
        "services" : "00000001",
        "lastsend" : 1341005009,
        "lastrecv" : 1341005008,
        "conntime" : 1341004990,
        "version" : 60001,
        "subver" : "/Satoshi:0.6.2/",
        "inbound" : false,
        "releasetime" : 0,
        "height" : 186813,
        "banscore" : 0
    }
]

I like it.