Add DAO data model architecture

[ctindogaru]

This PR is a 1:1 copy of https://github.com/near-daos/sputnik-dao-contract/wiki/%5BDRAFT%5D-DAO-Data-Model-Architectures to allow easy feedback (via PR comments) on the original proposal.

[ctindogaru]

Can we take a more granular approach and only focus on the governance module for now? There are too many big changes happening at the same time (governance + extension + user).

I would start a different thread on extension_modules after we agree on the governance module.

[ctindogaru]

What voting mechanisms can we have for a given proposal? I can only think of 3:

• equal voting rights (the current one)
• custom token voting. Each DAO can have a governance token and based on the amount that each member holds in that token, they will have different voting rights.
• weighted voting. You manually assign different weights for each member when you're creating the council.

[ctindogaru]

I think we only need governance_module and the existing votes here. I don't see ballots, outcome, metadata as necessary.

Then, in the governance_module you would have a method called compute(votes) and also a state (to represent the weights for each member, the governance token etc.).

With that in mind, you would call compute(votes) every time when act_proposal is called. Basically, this portion of the code will be replaced with a call to compute(votes):

            Action::VoteApprove | Action::VoteReject | Action::VoteRemove => {
                assert!(
                    matches!(proposal.status, ProposalStatus::InProgress),
                    "ERR_PROPOSAL_NOT_READY_FOR_VOTE"
                );
                proposal.update_votes(
                    &sender_id,
                    &roles,
                    Vote::from(action),
                    &policy,
                    self.get_user_weight(&sender_id),
                );
                // Updates proposal status with new votes using the policy.
                proposal.status =
                    policy.proposal_status(&proposal, roles, self.total_delegation_amount);

[ctindogaru]

Agree with this interface, but Outcome can be replace by the existing ProposalStatus.

[ctindogaru]

To conclude on this PR, I would strip out the extension module logic and put it in a different PR.

Also, I feel the governance module is more complicated than it should be. You only need the account id of the gov module to offload the logic there.

How would it work:

near call <gov_module> compute '{"votes": {"account1.near": "yes", "account2.near": "yes", "account3.near": "no"}}' --acountId <caller_id>

Then, the gov_module would know the weights for account1.near, account2.near, account3.near and also the quorum so it will know how to compute the result based on the given accounts + the weights for each of the accounts + quorum.

[ctindogaru]

Note that I did not review the extension module. I feel that we should have a separate topic on that.