Market liquidity decimals may not have 18 decimals, and ordering of addresses relative to price mocks must be better handled in the tests

[mesozoic-technology]

Currently there's a preconception that our markets will be ETH/OVL adjacent, but this won't necessarily be true in the future.

In the future, the decimals of the liquidity token may not always have 18 decimals.

Therefore, we should put the base liquidity token's decimals into an immutable variable for the purposes of the liquidity depth computation so that the incorrect number of decimals will not wreak havoc on the open interest caps.

This will take a moment of thought because to test this correctly we should deploy real erc20 contracts with the relevant decimals, but it does not look like brownie can deploy contracts at arbitrary addresses, even locally.

There is currently a calculation that depends on the ordering of addresses that is right now really just crossing its fingers as to whether the ovl/weth ordering respects the same ordering as our price feed for axs/weth.

            _ovlPrice = OracleLibraryV2.getQuoteAtTick(
                int24((_ticks[0] - _ticks[1]) / int56(int32(int(macroWindow)))),
                1e18,
                ovl,
                weth
            );

Possible solutions are to

1. keep deploying mock erc20s until we get address hierarchies that map onto the price feeds we are consuming
2. figure out completely how to make synthetic feeds, which I have made some progress on

I'd favor solution #2 the most there.

[mesozoic-technology]

Further reflection on how the market liquidity token not have 18 decimals could be important for Overlay:

Consider the possibility that once OVL is live and thriving, a project wants to enter a partnership that involves a new OVL/ERC20 market. For instance, when OVL is multi chain, maybe a governance proposal is introduced by a new chain that wants to create markets on their chains with OVL, and they want to heavily subsidize pools on their network with their native token.

Nothing's to say this native token will have 18 decimals, could be 6.

It is better to offload all external context than to demand more awareness of the deployment when it comes around.

As much as possible, it should be programmed to find and set the appropriate environment variables.