DerivaDEX security record

Compared to other governance logic, `Governance` is a facet of the `DerivaDEX` main proxy contract. All `DerivaDEX` facets share the same state (`InsuranceFund`, `Governance`, etc.). Transfering ownership to self using `transferOwnershipToSelf()` and allowing `diamondCut()` to be called by a governance proposal is a risk since it will allow majority group or an attacker as explained in the "DoS Attack" issue to intoduce malicious code that will be executed in the context of the `DerivaDEX` contract, thus allowing access to insurance fund stakers assets or any other state variable in the contract. On a more obvious way, a proposal can also contain a direct transaction that transfers users staked assets from insurance fund to any address. The FUD created around such action is enough to hurt `DerivaDEX` image, even if the governance proposal fails. Please note that malicious proposals cannot be canceled unless the proposer address' voting threshold falls below the `proposalThreshold` as implemented [here](https://github.com/apalepu23/derivadex_v1/blob/6bb9ac918e87bc416966b385cc5800cd7c310953/packages/protocol/contracts/facets/governance/Governance.sol#L387).

As it presently is constructed, the contract is vulnerable to the [allowance double-spend exploit](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/b4f87bb8fc25fb07f73099701e39e167a3d36465/contracts/token/ERC20/ERC20.sol#L71-L78), as with other ERC20 tokens.

The following additional privileged roles were noted as of commit `7194839`. In `InsuranceFund.sol`: 1. The admin can invoke `extendInsuranceMining` to extend the mining final block number arbitrarily. In `HDUMToken.sol`: 1. Users addresses can be blacklisted individually; 1. All main ERC20 functions can be paused; 1. Tokens can be minted for any selected address without limitation; 1. Users assets can be burned by coin factory admin using the `redeem` function.

The function `advanceOtherRewardsInterval` checks how much COMP and Aave is owed to the `InsuranceFund` contract, which will be rewarded to stakers proportional to their deposits. If users have not claimed their owed rewards in previous intervals, the unclaimed rewards are aggregated into the same total. This unclaimed amount is then re-distributed proportionally across all users. As an example, suppose there are two users, both have equal stakes, and the fund has earned 100 COMP during an interval. If one user invokes `claimDDXFromInsuranceMining`, they will receive the 50 COMP, and 50 COMP will remain unclaimed. Now, suppose another interval passes and the contract has earned another 100 COMP (now totaling 150 unclaimed COMP). If the same user invokes `claimDDXFromInsuranceMining`, they will now be rewarded 75 COMP, bringing their total to 125 COMP, which is more than 50% of the total earned rewards. Thus, in order to maximize reward payouts, users must claim their rewards every interval, which may not always be desirable from a gas-cost perspective.