Update query type of LocalStateQuery protocol for Shelley

[mrBliss]

See #1366. Shelley will need more/different types of Queries, so the query type of the LocalStateQuery will need to be extended/updated to accommodate for the new functionality required by the Shelley wallet.

[dcoutts]

In particular extra things this will cover include:

• info about stake pools (probably just bulk info)
• reward account values (probably just query individual accounts)

[mrBliss]

Copying from #1366 (comment)

I am not sure where to log this so, for lack of a better place I'll put it here:

For Byron, @dcoutts has already captured the requirements / needed pieces of the ledger state (updatable protocol params & confirmed update proposals).

For Shelley, we are looking for:

* All the Byron's requirements

* The rewards given to a particular account. The latest balance would be a must-have, while the complete history would be a nice-to-have (although I am not sure of the feasibility for the node. This is something we would likely keep in an explorer).

* The stake distribution of past epochs, per epoch, (up to a certain age, last `k` is nice but also much more than what we would need) in terms of pools ids (who owns what?).

* The total reward amount distributed in past epochs, per epoch (i.e. the `R` in the incentive paper).

Cheers!

[KtorZ]

*Small precision, I was probably a bit tired when I wrote this 🙃
About the stake distribution, what I meant to say was that, having the last k is nice but NOT sufficient. We need to know the stake distribution of at least the previous epoch. So we are looking more for 10*k than k (although, I assume this particular ratio is not set in stone).

[edsko]

So @dcoutts , @mrBliss and myself discussed this. Our current proposal is:

• The Shelley ledger is extended with rules (and state) for maintaining stakepool performance, which can then easily be queried through the LocalStateQuery protocol.
• We do not offer the wallet any historical data. If/when the wallet needs to present historical data to the user, it is responsible for replaying the chain as it sees fit (it can of course reuse the ledger library to do so) -- if useful, it could do this out-of-process.

There isn't too much point having the node implement a view on historical data, as in either case the user's machine would now temporarily have two copies of the ledger state in memory. The only advantage might be that the node could maintain additional snapshots of the ledger state (say, one per epoch) but that too is probably excessive for most users (currently that would result in about 11 GB of data), although it might be an option for exchange nodes.