suppliers funds loss because attacker can transfer his collateralized tokens when health factor is below liquidation threshold by reentrancy attack during executeLiquidateERC20() logic and transferring collateralize 
Audit: 2022-11-paraspace-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2022-11-paraspace/blob/c6820a279c64a299a783955749fdc977de8f0449/paraspace-core/contracts/protocol/libraries/logic/LiquidationLogic.sol#L150-L273
https://github.com/code-423n4/2022-11-paraspace/blob/c6820a279c64a299a783955749fdc977de8f0449/paraspace-core/contracts/protocol/libraries/logic/LiquidationLogic.sol#L516-L556
https://github.com/code-423n4/2022-11-paraspace/blob/c6820a279c64a299a783955749fdc977de8f0449/paraspace-core/contracts/protocol/libraries/logic/LiquidationLogic.sol#L860-L881
https://github.com/code-423n4/2022-11-paraspace/blob/c6820a279c64a299a783955749fdc977de8f0449/paraspace-core/contracts/protocol/libraries/logic/GenericLogic.sol#L188-L195


# Vulnerability details

## Impact
Function `executeLiquidateERC20()` is for liquidating a position if its Health Factor drops below 1. The caller (liquidator) covers `liquidationAmount` amount of debt of the user getting liquidated, and receives a proportional amount of the `collateralAsset` plus a bonus to cover market risk.
by this issue, attacker can liquidate his/her account(with another address) and perform reentrancy and transfer his collaterals while attacker's account has bad health factor and by doing so attacker would steal other suppliers tokens. the problem is that code don't follow check-effect-interact pattern in `executeLiquidateERC20()` logics. before transferring debt tokens or collateral asset, code set values for `setBorrowing()` and `setUsingAsCollateral()` and then code makes external call which gives attacker this opportunity to perform reentrancy attack when protocol contracts storage is in wrong state(borrowing set as false for borrower in liquidation token while borrower still has debt). this wrong state would increase health factor of the account which would be possible to transfer other collaterals of the user while in reality user has bad health factor. (if you have question about the issue please contact me)

There are other impacts too, attacker can manipulate `setBorrowing()` and `setUsingAsCollateral()` for user or his/her account and PTokens and make those values to be in wrong states(for example user has collateral but usingAsCollateral would be false or the opposite)

## Proof of Concept
if user had bad health factor then any other user can call liquidation function. during the call to `executeLiquidateERC20()`, if all user's debt in that liquidationToken is going to get paid contract sets `userConfig.setBorrowing(liquidationAssetReserve.id, false)` and then it makes an external call if liquidator sends ETH, contract swap required amount of ETH for wETH and sends extra amount back to liquidator(function `_depositETH()`) which gives attacker to perform reentrancy attack. as borrowing has been set to false for that `liquidationAssetReserve.id` so health factor of user would increase, and it would be possible to perform some action without failing because of bad health factor. there are reentrancy protection in p