Vote bits sync.

[chappjc]

Remaking #32 after new repo was created. Original un-squashed branch here.

This implements vote bits (re)synchronization/repair. Please test and review. All of the new or modified functionality is tested on a testnet pool, but there may be more attack protections that should be made (walletRPCHandlerize any of this?).

In terms of behavior:

• On startup of dcrstakepool, a full vote bits sync of all tickets owned by the pool is performed. It will be skipped if importscript gets run since that takes a long time.
• /tickets POST (set bits) has a short timeout so a large number of tickets does not block page loading.
• A flash message will indicate that a tickets sync is in progress. No tickets are shown in this period.
• /tickets GET checks for consistency of vote bits between wallets and launches a resync when needed. A flash message is also used in this case, and no tickets are shown (as shown in image below).

Implementation:

• A RWMutex is used so multiple readers can access ticket vote bits data, while a single writer can lock before doing a set of any vote bits.
• An atomic is used to make a kind of "try lock" that the /tickets page can check without blocking.

It needs a dcrrpcclient version change for the new GetTickets RPC.

Issues:

• getstakeinfo's immature includes unmined, whereas gettickets does not include mempool. This prevents the startup check from passing int(gsi.Live+gsi.Immature) != numLiveTickets while tickets are in mempool. All is well after tickets get mined. Workaround is to avoid such a check, and only check that the wallets agree with eachother w.r.t. gettickets.
• On startup, if wallets are out of sync w.r.t. address indexes or scripts, then it is likely that SyncVoteBits will either report different numbers of tickets (before they are processing the import/sync) or report -4: syncing... here Rather than quit, the solution is to just skip the full ticket vote bits sync (check and repair). The vote bits are repaired on-demand via /tickets.
• Ensure the new SetTicketsVoteBits and GetTicketsVoteBits (note plural) are used where appropriate for efficiency

Startup auto-repair:

User changing vote bits, if process exceeds 3 seconds:

[jolan]

Tested with various startup/on-demand syncs with anywhere from 1 to 1400 tickets and all cases worked well for me.

I'd rather just do any further improvements in a separate PR since this is big enough and works well as-is.

Thank you for your work on this!

[chappjc]

So it seems either the setticketsvotebits (plural tickets) msg and handler vanished in one of the dozen or so rebases or it was never implemented while this was waiting on the functionality in dcrrpclient and dcrwallet... Either way, this needs a fix.