feat: implement governance features in BigIncGenesis contract

[ikemHood]

Overview

This PR implements comprehensive governance features for the BigIncGenesis contract, enabling decentralized withdrawal management.

Changes

• Governance withdrawal functions: Added submit_withdrawal_request, execute_withdrawal, and set_governance_parameters
• Governance view functions: Added get_withdrawal_request and get_governance_parameters
• New data structures: Created WithdrawalRequest and VoteStatus structs for managing withdrawal requests and voting status
• Event emissions: Updated event system for withdrawal requests and governance parameter changes
• Testing infrastructure: Added comprehensive tests for governance parameters and withdrawal request functionalities
• Mock contracts: Introduced contract for testing purposes

Key Features

• Decentralized withdrawals: Shareholders can vote on withdrawal requests submitted by the owner
• Configurable governance: Quorum percentage and approval thresholds can be adjusted
• Secure execution: Withdrawal requests can only be executed after meeting quorum and approval requirements
• Time-based deadlines: Each withdrawal request has a deadline for voting

Testing

• Added test coverage for governance parameter setting
• Added test coverage for withdrawal request submission and execution
• Included partner share cap testing

This implementation ensures that fund withdrawals require community consensus while maintaining the security and integrity of the contract.

Closes #18

[CollinsC1O]

I want you to make some changes. check the details in the comment section

[CollinsC1O]

Hey @ikemHood Gm

Your implementation provides an addition to the withdrawal_progress_amount which is perfect but I want you to improve this because when withdrawal executes or gets cancelled, this amount should be subtracted to free up balance for future requests. i.e you should provide an implementation that reduces progress amount after successful transfer, (subtract from the progress), considering that the withdrawal has been executed. Do same if the request gets canceled
for example:
let current_progress = self.withdrawal_progress_amount.read(token_address);
self.withdrawal_progress_amount.write(token_address, current_progress - amount);

Secondly, I see that the WithdrawalRequest struct has a field for is_cancelled which tells if cancelled or not but you did not provide a function implementation for this, Can you implement this. And here you can reduce withdrawal_progress_amount once request is cancelled.
Example
fn cancel_withdrawal_request(ref self: ContractState, request_id: u256) {
// Update is_cancelled = true
// Reduce withdrawal_progress_amount
}

Lastly, We using just only URI length + deadline is definitely weak. Consider this, if we’ve another url with same length as this and same deadline it will give same hash I.e (Different URIs with same length + same deadline = same hash!). now I want you to hash the actual milestone_uri content, not just it’s length and use this to get the expectation hash instead.

[CollinsC1O]

Hello @ikemHood I sent you dm on telegram

[CollinsC1O]

Considering what we discussed. This only but a reminder,
so if a person with high shares weight vote for a request to be granted and then we have 2 or 3 others with less weight voting against, their vote should not override that of the person with higher weight, say the person with higher weight got 25 shares weight and the other voters voting against, got 2 weight each you see all their weight combined do not reach his so should not counter the vote of the person with higher weight. This gives us a wealth based voting system.

So the governance parameter implementation would change concerning the threshold and also the request withdrawal function. Also the voting due time should be fixed to limit it to a specific period and also prevent voting afterwards.
If quorum expires, each vote has a deadline from when the request is registered if one person approves so after that fixed time lets say two days, nobody should be able to vote and then the vote for that period counts

There should be a trigger mechanism for the execute_withdrawal ensuring all conditions are checked

If the request has passed its maturity date and nobody voted, and then somebody tries to vote, that should be a mechanism to trigger it too.

Also event should be fully emitted so shareholders get hand on the requested withdrawal

This is but a reminder of our discussion, hope you've been making progress

[CollinsC1O]

Hello @ikemHood Gm
said to check in on you and know the state of things, haven't seen any commit yet, hope you've been alright.
The above message is just a reminder of our previous discussion

[CollinsC1O]

hello @ikemHood can you ensure that your tests passes successfully and your code well formatted

[ikemHood]

[ikemHood]

@CollinsC1O

[CollinsC1O]

@CollinsC1O

you will get a respond in no distant time

[CollinsC1O]

Hello @ikemHood Gm
I want you to ensure that the owner/artist (who is the requester) of the contract can not vote and also for the quorum I see that you made an implementation which effect that if a single voter is not disputed, it still gets approved but now I want it to be that no matter what the voters weight is, so long as they are not disputed it should still get approved even if the voters weight is 0.5

[ikemHood]

Hey @CollinsC1O

Done