feat(perpetual-liquidatable) Implement Liquidatable and replace expiry logic with emergency-shutdown logic

[nicholaspai]

Motivation

#2024, #2048

Summary

This PR copies the ExpiringMultiparty's Liquidatable contract and strips out expiry logic. This contract imports all of the logic from the PerpetualPositionManager introduced in #2072. Unit tests were also copied from ExpiringMultiparty and minimal changes were made to replace expiry logic with emergency shutdown logic.

Details

Major changes:

• Add _getOraclePrice(timestamp) back to PerpetualPositionManager because the Liquidatable contract needs to call it on the liquidation-timestamp.
• createLiquidation should be blocked during an emergency shutdown, for the EMP it is blocked post-expiry.

Issue(s)

Initial implementation of #2024
close #2048

A Follow up PR will change the _settle logic to incorporate a cumulativeFundingRateMultiplier, but this is likely blocked until an initial implementation for #2030 is built.

Open Questions
Is there any reason to disable Disputes and withdrawals of liquidation/dispute rewards following an emergency shutdown (for the perpetual contract)?

• Cons to Disabling: If someone gets liquidated incorrectly right before shutdown, then they cannot recover their funds
• Pros: Guarantees that no collateral leaves the contract in a shutdown

I’m inclined to follow the EMP pattern and allow disputes/withdrawal of liquidation/dispute rewards. This implies that once a sponsor is liquidated, their collateral has already “left the contract” so we should not freeze these funds

[nicholaspai]

Liquidatable needs access to this internal method to get the price for a specific liquidation time

[chrismaree]

that's a good point. needs to get it at dispute time.

[nicholaspai]

This test and the next one replace expiry logic with emergency-shutdown logic

[chrismaree]

Great PR @nicholaspai! very simple in that we basically had to change only one modifier to get this to work with the perpetual contract. Tests are also 99.9% the same as before except for one small refactor. I'm happy with it :)

[chrismaree]

that's a good point. needs to get it at dispute time.

[chrismaree]

Regarding your open question, as discussed offline, I think it best to keep the same EMP logic as a sponsor could be incorrectly liquidated right before the contract is emergency shutdown.

[coveralls]

Coverage increased (+1.4%) to 93.15% when pulling dbcff0f on npai/initial-liquidatable into 3129fc8 on master.

[mrice32]

@nicholaspai thoughts on copying the contract over in a separate PR? That way, we can tell what parts changed and need to be reviewed? Otherwise, we'll probably miss the parts you changed.

[nicholaspai]

@nicholaspai thoughts on copying the contract over in a separate PR? That way, we can tell what parts changed and need to be reviewed? Otherwise, we'll probably miss the parts you changed.

Normally i'd say yes, but there are very few changes. I'd recommend using a diff checker tool to see that I only removed the expirationTimestamp from the constructor and replaced the one onlyPreExpiry() modifier in front of createLiquidation() with notEmergencyShutdown

[nicholaspai]

Need to increase heap size, similar to the coverage job`, to accomodate more tests: lerna/lerna#2226 (comment)