Follow up to #3049

• Clarify whether the maximum difference should be TotalVotingPower or 2*TotalVotingPower (Normalize priorities to not exceed total voting power #3049 (comment))
• Consider whether we need to avg the priorities more frequently (Normalize priorities to not exceed total voting power #3049 (comment))

Update: TODOs we (@ancazamfir, @cwgoes, @liamsi) collected during a call:

• use max int32 as a bound for voting power while keeping voting power as int64; also make sure that total voting power doesn't exceed int64 (to avoid and remove clipping) (SDK-side PR: R4R: power reduction for Tendermint cosmos/cosmos-sdk#3400) (@liamsi)
• make sure the priority computations don't exceed int64, e.g. during scaling if we do vp * tvp/.. (@liamsi)
• figure out bound for difference (max - min priority) in n-validator case, ensure we respect it (we should not normalize more tightly) (@cwgoes, @liamsi )
• formalize fairness proof and priority difference bounds in LaTeX doc (@cwgoes, @liamsi )
• treat validator set changes as a set and apply them atomically Treat the validator updates from the application as an unordered set #3181 treat validator updates as set #3222 (@ancazamfir )
• While addressing Treat the validator updates from the application as an unordered set #3181 move priorities.go:updateValidators() to validator_set.go and write unit tests in validator_set_test.go (@ancazamfir)
• update spec/documentation (@ancazamfir)

Update (Feb 8):

#3181 has been fixed. But the fix included a large refactor of the validator updating code that spawned some follow up requests in the reviews. Please see the reviews in #3222. Main items for follow up:

• Better error handling instead of panicing (treat validator updates as set #3222 (comment))
• Test cleanup if possible (treat validator updates as set #3222 (comment))
• Cleanup processChanges function (treat validator updates as set #3222 (comment))
• Update ABCI documentation to specify validation rules around what is an invalid update (treat validator updates as set #3222 (comment))