Front-running vulnerability in the liquidate function

Summary

As liquidate involves multiple transactions, an attacker could watch for pending liquidations and front run to steal some collateral

The key issue is that liquidate makes multiple state-changing transactions in sequence:

It calls _repay to repay part of the debt and update the shares.
It transfers the liquidated collateral to the msg.sender.
It transfers the liquidated underlying vault shares to the msg.sender. An attacker could watch for pending liquidate calls, and quickly call takeCollateral after step 1 and before steps 2-3 to steal some collateral. For example:
Alice calls liquidate on Bob's undercollateralized position. This is broadcast to the pending transaction pool.
Eve sees Alice's liquidate transaction in the pending tx pool.
Eve quickly calls takeCollateral to remove some of Bob's collateral before Alice's liquidate completes.
When Alice's liquidate finishes steps 2-3, some collateral has already been taken.

An attacker can steal collateral rewards

Manual Review

Use a "state" variable to gate access to sensitive logic