Theoretical reentrancy attack when TYPE_MINT_BURN proposals are executed
The senate can pass a proposal to mint or burn tokens.\\n```\\n       if(proposals[_proposalId].actionType == TYPE_MINT_BURN) {\\n           (address _token, address _to, uint256 _amount, bool _flag) = \\n               abi.decode(proposals[_proposalId].payload, (address, address, uint256, bool));\\n       if(_flag) {\\n           IXMozToken(_token).mint(_amount, _to);\\n       } else {\\n                    IXMozToken(_token).burn(_amount, _to);\\n       }\\n       proposals[_proposalId].executed = true;\\n       }\\n```\\n\\nNote that the proposal is only marked as executed at the end of execution, but execution is checked at the start of the function.\\n```\\n        function execute(uint256 _proposalId) public onlyCouncil {\\n                 require(proposals[_proposalId].executed == false, "Error: \\n            Proposal already executed.");\\n        require(proposals[_proposalId].confirmation >= threshold, "Error: Not enough confirmations.");\\n```\\n\\nInteraction with tokens should generally be assumed to grant arbitrary call execution to users. If the mint or `burn()` calls call `execute()` again, the proposal will be executed twice, resulting in double the amount minted or burned. Specifically for XMoz, it is not anticipated to yield execution to the to address, so the threat remains theoretical.
Follow the Check-Effects-Interactions design pattern, mark the function as executed at the start.
```\\n       if(proposals[_proposalId].actionType == TYPE_MINT_BURN) {\\n           (address _token, address _to, uint256 _amount, bool _flag) = \\n               abi.decode(proposals[_proposalId].payload, (address, address, uint256, bool));\\n       if(_flag) {\\n           IXMozToken(_token).mint(_amount, _to);\\n       } else {\\n                    IXMozToken(_token).burn(_amount, _to);\\n       }\\n       proposals[_proposalId].executed = true;\\n       }\\n```\\n