[Communities] Governance for communities

[pandres95]

Implements the multi-governance for communities:

This implementation exposes the following methods

• set_decision_method: allows a community management origin to set which is the decision method for a community.
  Limitations

  • This value is not synced-up with Tracks, since there's no easy way to retrieve the OriginCaller used on track_of having the TrackId. Instead, the sync-up must be made manually using the appropriate calls (probably using a Root origin).

• vote: Let a community member cast a vote for a poll opened on a track corresponding to the community.
  Limitations

  • This design considers only one track per community. For future implementations, the design should consider a structure that allows vote track the community_id derived from the membership_id and the poll class to be compared (maybe, restricting to Class = Into<T::CommunityId>).
  • When using Vote::AssetBalance, funds are held, making them effectively unusable on other applications.

  Caveats

  • To solve the issue of changing the vote over time when using Vote::AssetBalance, I needed to first release the hold, then hold the new amount. This is a bit more resource-intensive and may be punished on benchmarks. A permanent solution implies implementing InspectFreeze and MutateFreeze on pallet-assets. I can work on that as a separate PR to upstream on polkadot-sdk.
  • For Vote::Rank we have to manually sum for ranks of all members to get the max possible rank sum, and implement the concept of vote_multiplication. These implementations might change over time, as strategies to calculate vote multiplications for ranks can vary between communities.
  • For Vote::Membership we have to manually count for memberships in each community, as there's not a method for that on membership::Inspect. This implied storing MembershipsCount and mutating values on add_member/remove_member.
  • Vote::NativeBalance uses RuntimeHoldReason as FreezeId, something that requires to be set on pallet-balances as such. While unusual, this allows for maximum code reusability. If there's a need to handle it differently, we'll need to discuss in the scope of this PR.

• remote_vote: allows for removing a vote, on a poll that's ongoing.

• unlock: allows for releasing funds for a vote casted on a poll that's not ongoing (either cancelled or finished).