go-kosu: implement validator removal and subcommand

[gchaincl]

Overview

Implements validator removal and `kosu-cli tx update-validator sub-command. Useful to test this scenario.

Description

Given an incoming Validator Tx we check the amount:
- if == 0: use the corresponding validator's power to confirm the tx and update the balance with 0
- if != 0: use the tx amount as confirmation power.

validators updated with 0 balance will be removed from the store

Testing

To test this, a new command has been introduced: kosu-cli tx update-validator <block> <pubkey> <address> <power> [flags]:

0. start the testnet

make testnet

1. check the current validator set:

curl localhost:8000/validators | jq '.result.validators[].voting_power'

2. Update a validator power

./kosu-cli --abci http://localhost:8000 --home ./testnet/node0 tx update-validator 1 r9dq+UvR+DzAmKhuo8VTk+i4OuSLA4uUPxVmKI1ucas= address 6000000000000000000

3. check the current validator set

curl localhost:8000/validators | jq '.result.validators[].voting_power'

4. Remove the validator from set

./kosu-cli --abci http://localhost:8000 --home ./testnet/node0 tx update-validator 2 r9dq+UvR+DzAmKhuo8VTk+i4OuSLA4uUPxVmKI1ucas= address 0

5. check the current validator set

curl localhost:8000/validators | jq '.result.validators[].voting_power'

[gchaincl]

@hrharder I'm tagging this as a WIP cause there's still some details that I'd like to discuss with you.

[hrharder]

Great, this looks good so far Gus! I will play around with it today.

[gchaincl]

cool, let me know how it goes

[hrharder]

go-kosu: please

Looks like the git-gods listened, all appears to work! Great job :)

[hrharder]

This looks good to me, the only outstanding issue I see is dealing with confirmed witness Tx's. We'll have to figure out the best way to safely prune them.

Perhaps during execution of each new WitnessTx, we check if there are any in the store that are more than N blocks old, and if so, we can assume they will never be confirmed (or already have been) and can delete... Just an idea. We can discuss elsewhere.

[gchaincl]

@hrharder do you think we should implement witnesstx pruning before merging?
IMO we can open a new PR when we define the behavior we want

[hrharder]

I agree, let's merge this in and delegate that to a new PR.