Implement MasterStrategyV1

[nourharidy]

Problem

1. Currently we have 2 developed and somewhat battle-tested strategies running in production and a third being currently developed. Changing a vault's strategy requires a 2-day timelock to protect users from rogue strategies. But that should apply to new strategies only, not ones that were already timelocked and added to a different vault. This allows us to quickly upgrade vaults to relatively safe and proven strategies based on market conditions.
2. We don't have a unified interface for monitoring and managing strategies externally. This prevents us from creating tooling that can be used to efficiently manage parameters and setters.
3. We don't have a unified role management system to allow multiple addresses different levels of access to strategy parameters and setters. This resulted in vaults becoming separate isles where each requires one address to be in full control of all privileges and creates a single point of failure in times of emergency (e.g. Harvest Finance upgrade). Separation between vault and strategy owner (currently each vault owner is strategy owner) is also necessary to continue to move quickly after vault ownership moves to governance.
4. Vaults support only one strategy at a time which can limit us in capacity when TVL grows quickly. Yearn v2 solved this problem by rewriting their vaults, I think we can/should avoid that.

Solution

Overview

Implement a single MasterStrategyV1 middleware contract that will replace all current and future strategies. Other strategies would be only controlled by this single contract.
MasterStrategyV1 solves issues 1-3 listed above. Support for multiple strategies per vault can be added in V2 to reduce complexity of the initial version.

Vault => Strategy Mapping

The master strategy should redirect invest(), divest() and calcTotalValue() calls to the appropriate strategy while determining the requesting vault based on the msg.sender value and route funds between them.
The mapping will also function as the "official" source of truth for vaults offered by Inverse.

Strategy Factory Whitelist

MasterStrategyV1 should include a global strategy factory whitelist that allows instant migration of all vaults to any whitelisted strategy. Adding a new strategy factory to the whitelist must be timelocked for at least 2 days. Removing factories can be instant. This also allows users to watch a single global timelock contract instead of a timelock per vault.

The strategy factories would follow a new unified interface with a single function create(address) returns (address) method where input is the vault address and the output is the strategy contract address. Factory can only be called by the master strategy. Factory will determine other strategy params (e.g. yToken or fToken address) by querying the vault directly (e.g. if underlying() == DAI, use built-in fDai address). Changes made to each factory must be timelocked.

Access Control

We should inherit OpenZeppelin's AccessControl (or a similar contract) to create different levels of access which can be authorized only by governance. This allows governance to trustlessly delegate some power to strategists/devs while still keeping the ability to take power back by a vote.
https://docs.openzeppelin.com/contracts/3.x/api/access#AccessControl

Backward compatibility

The master strategy should implement IStrat interface for backward compatibility with existing vaults running in production.

Conclusion

MasterStrategyV1 is Inverse's first step towards becoming a single unified protocol rather than a group of separate contracts. The architecture outlined above allows for flexible strategy upgrades, better access control and total governance control while preserving the same trust assumptions for users. Implementing this architecture is also backward compatible with existing vaults, meaning that we can avoid the costs of a full user migration.