Config: Check that cold wallet key and voting wallet key are not the same

[jholdstock]

According to @dajohi there have been cases in the past where users have attempted to use the same wallet and/or account for both voting and collecting voting fees.

We can help VSP operators to avoid these kind of mistakes by adding some simple checks to the code, either check if the 2x pubkeys are identical, or check if they belong to 2x distinct wallets. The former is trivial to implement, I am not sure if RPCs exist for the latter.

[JoeGruffins]

While working on this issue I had the idea that the voting key should be taken out of the config all together. The readme specifies that the "default" account should be used anyway. We can get that pubkey programmatically and there's no reason to have the user input it then check it.
There is the chance that an operator has for some reason used a different account. I don't think it will cause a problem to switch accounts midstream, but I will test it out on my server. If anyone has a reason for leaving the voting pubkey in the conf please let me know, otherwise I think I will go the direction of removing it.

[jholdstock]

Having dcrstakepool programmatically retrieve the voting wallet pubkey seems like a good idea. I guess the solution would be something like:

• Add a new RPC in stakepoold which retrieves the MasterPubKey for default account on the hot voting wallet.
• On startup, dcrstakepool gets calls this new RPC on each stakepoold instance. Any RPC failure or mis-matched MasterPubKey causes a fatal error - dcrstakepool does not start up. If all instances of stakepoold report the same pubkey, continue starting up and use that key where we previously use the key defined in config.
• Mark the config item as deprecated
• Update the README.

@chappjc any thoughts about this?

[chappjc]

Solution concept is good and will be a welcome change to ops. I did a very superficial review of #422, but it looks to be going in a good direction. I'd like to review that more closely though.