Refactor Democracy #5248
Description
Democracy module currently works in two stages: votes are registered initially, then funds possibly locked only at the point that votes are counted. In the case of a high number of votes, this can lead overweight on_initialize in blocks, which is bad for consensus.
A more robust design would be to lock funds immediately upon voting (a cancel_vote extrinsic could accordingly reverse that operation if done before the vote deadline) and keep a running tally of voting funds, thereby making the operation entirely incremental and avoiding any large compute/storage payloads at the end of blocks.
Unlocking should happen lazily, to avoid the need of keeping large Vecs of account IDs around. Votes and directions should remain in storage until either the vote is cancelled, the funds are unlocked because the vote was against the final decision or the funds are unlocked because the conviction lock period is over.