DAC voting, base fee proposal

[evlekht]

Why this should be merged

This PR adds feature of DAC proposals and voting which is executed with transactions.
Also, this PR renames all DAO entries to DAC.

How this works

There are 3 new transactions:

• AddProposalTx, it contains proposal bytes and proposer address/auth. In addition to fee burning, this tx will bond some tokens. Also, this tx must be additionally signed by proposer.
• AddVoteTx, it contains vote bytes, voter address/auth and proposalID (id of addProposalTx). This this must be additionally signed by voter.
• FinishProposalsTx is system tx. It will finish all expired (both successful and failed) and early (again both successful and failed) proposals, tx body contains those proposal ids.

Vote and proposal fields in txs represented by bytes, not some structure or interface. This is done in order to be able to add new proposal types without needing to update codec.

Block builder will try to build block with FinishProposalsTx when there are early finished proposals or expired proposals.

Proposals execution and semantic verification logic resides in its own proposalExecutor type methods in txs/executor package. Proposals are calling this methods via visitor pattern.

Proposals and votes logic are encapsulated behind interfaces, which could be implemented by different types. This PR adds BaseFeeProposal and SimpleVote types.

SimpleVote is vote that simply points to specific proposal option index, e.g. baseFee proposal with options [ {newFee: 100}, {newFee: 200} ], and simpleVote {0}, where vote is for newFee 100 option.

BaseFeeProposal is proposal to change base fee, its options are new base fees. This proposal can only be proposed by caminoProposer address state role, which is introduced in this PR as well.

All proposals can be voted only by addresses that were active validators at the moment of addProposalTx block execution. While its not required for voters to still be active valaditors when they vote, it is required for them to still be consortium members.

Commits

PR consists of 3 commits:

1. Commit with base logic except most of proposal-related tests, cause the need some actual proposal implementation.
2. Commit with simpleVote and corresponding tests
3. Commit with baseFeeProposal, corresponding tests and all tests that were excluded from (1)

How this was tested

Unit-tests, integration tests

[c4t-ag]

Nice work!
There are some minor things (comments), and some general things which should be at least discussed:
1.) If possible (not sure if it makes sense) the final PR should have at least 2 commits, the base implementation and another commit the basefee specialization. This would help to see what is required to implement a more complex one (thinking about a multi option proposal where the exit is not necessarily a simple 50% one.
2.) It should be evaluated (with @Noctunus because the idea was initially from him) to operate with a fee multiplier instead setting the basefee. This could then be applied to all spialized Fees.

[c4t-ag]

Some more comments for additional comments :-)

[evlekht]

@c4t-ag
I added "version" without base fee proposal, see last 2 commits. First commit removes all base fee related stuff, then second adds it back. As you can see from first commit, it will unfortunately remove a lot of transaction tests, cause we need at least one proposal type in order to create them. And I don't want to add dummy proposal type, cause then we'll need to modify proposals visitors to include this type.

[c4t-ag]

Great work, go!