stake-snapshot and pool-params query commands

[kevinhammond]

This PR provides two new query commands that should be useful to SPOs who are using the CNCLI set of tools, for example (as well as for internal IOG purposes):

cardano-cli query stake-snapshot --stake-pool-id <poolid>

cardano-cli query pool-params --stake-pool-id <poolid>

These commands allow users to access two pieces of information from the ledger state

1. stake snapshots
2. pool parameters, including retirements

The stake snapshot returns information about mark, set, go snapshots for a pool, plus the current total stake that can be used in a 'sigma' calculation:

cardano-cli query stake-snapshot --stake-pool-id a3e71398e80739522e907c35b8f652064e5268e62e9b78a9603f6b98 --mainnet
{
    "activeStakeGo": 200921353802160,
    "activeStakeMark": 209901353802160,
    "activeStakeTotal": 32334956959700987,
    "activeStakeSet": 201571353802160
}

The pool parameters return three pieces of information: current parameters, future parameters and retiring information. They may be null if eg the parameters are not changing.

cardano-cli query pool-params --stake-pool-id a3e71398e80739522e907c35b8f652064e5268e62e9b78a9603f6b98 --mainnet
[
    {
        "publicKey": "a3e71398e80739522e907c35b8f652064e5268e62e9b78a9603f6b98",
        "cost": 340000000,
        "metadata": {
            "hash": "196eb1b2937af2c88647204920d19985501c99da3fc69e421a942b9b8f817e94",
            "url": "https://git.io/JTI4o"
        },
        "owners": [
            "6877dcb866858b2a4941351c98cd67202262bfd82a016cbbaa073927"
        ],
        "vrf": "11ad7c225b48721dbd9642de1ab05640fe53ab29af2df513f236cc7ac4617da6",
        "pledge": 0,
        "margin": 1,
        "rewardAccount": {
            "network": "Mainnet",
            "credential": {
                "key hash": "6877dcb866858b2a4941351c98cd67202262bfd82a016cbbaa073927"
            }
        },
        "relays": [
            {
                "single host address": {
                    "IPv6": null,
                    "port": 3001,
                    "IPv4": "34.91.217.120"
                }
            },
            {
                "single host address": {
                    "IPv6": null,
                    "port": 3001,
                    "IPv4": "34.91.176.78"
                }
            },
            {
                "single host address": {
                    "IPv6": null,
                    "port": 3001,
                    "IPv4": "34.91.150.76"
                }
            }
        ]
    },
    null,
    null
]

The main advantage over using query ledger-state is that these commands avoid the need to dump the full ledger state (time consuming and memory intensive - meaning they reduce the total system demands for SPOs), and will make it easier to support CNCLI and other tools. They also use existing internal operations (such as the ledger pool stake calculation), meaning that the information is guaranteed to be identical to that which the ledger is using (and without having to write scripts to extract/correlate the information).

I have decided to put these under 'query' rather than 'pool' since they are extracting info from the ledger state.

[AndrewWestberg]

I believe we need activeStakeMarkTotal, activeStakeSetTotal, and activeStakeGoTotal. The total active stake can change between each of the snapshots.

[Jimbo4350]

Right overall direction but some things need to be addressed.

[Scitz0]

1. I would like to request a change to the pool-params output to make it more clear what the three different sets returned mean. See suggestion below.
2. In addition to this, I would like for the future set an additional field called activeInEpoch containing what epoch the future pool update becomes active.

Current output:
An array containing three unnamed sets for current, future, and retired.

[
  {
    "publicKey": "0b08b536ba3afe21fbd826fb92bee897a3d1e575a7849b2e6c4659ab",
    "...": "rest of the fields"
  },
  {
    "publicKey": "0b08b536ba3afe21fbd826fb92bee897a3d1e575a7849b2e6c4659ab",
    "...": "rest of the fields"
  },
  null
]

Requested output:
My idea would be to have a schema like this instead, replacing the JSON array containing three unnamed objects with a key/value schema where active and future contains a JSON object(null for future if there are none) and retired the epoch number or null.
Makes it clean and easy to understand what is what.

{
  "active": {
    "publicKey": "0b08b536ba3afe21fbd826fb92bee897a3d1e575a7849b2e6c4659ab",
    "...": "rest of the fields"
  },
  "future": {
    "publicKey": "0b08b536ba3afe21fbd826fb92bee897a3d1e575a7849b2e6c4659ab",
    "activeInEpoch": 125,
    "...": "rest of the fields"
  },
  "retired": null
}

[Jimbo4350]

There is still some unnecessary diff in this PR that needs to be sorted out before I review the rest.

[Jimbo4350]

Unnecessary diff here and in other places.

[erikd]

Closing this in favor of #2560 because no one else has.