If a hook enabled by guard admin is then subsequently restricted or disabled (e.g. due to vulnerabilities), any existing rental order that uses the hook will be DOSsed and cannot be stopped
Audit: 2024-01-renft-findings
Severity: MEDIUM

# Lines of code

https://github.com/re-nft/smart-contracts/blob/3ddd32455a849c3c6dc3c3aad7a33a6c9b44c291/src/policies/Stop.sol#L211


# Vulnerability details

## Impact
Hooks can be added by Guard_Admin role through Guard.sol. And each hook can have different combination of options including `hookOnStart`, `hookOnStop`, `hookOnTransaction`.

When a hook previoulsy added by an Guard_Admin and then restricted or disabled by the admin due to discovered vulnerabilities or evolving project needs or external protocol risks, then any existing rental order that uses the hook will be effectively DOSsed. These rental orders cannot be stopped, and assets and erc20 payments cannot be transferred.

## Proof of Concept
A rental order can use as many hooks as needed, and these hooks might perform different utilities such as additional incentives provided by an external protocol. 

When rental order is created in the protocol with these hooks, each hook will be run at the start of the rental creation (`validateOrder()`), and also at the stop of the rental(`stopRent()`).

The vulnerability is in the Stop.sol - `_removeHooks()` function, which will revert  the entire `stopRent()` transaction if any hook from the order is no longer supporting `hookOnStop`. This is done through `!STORE.hookOnStop(target)` check. 

Suppose a popular hook was registered by Guard_Admin that provides incentives for rental, and a lot of rental orders are created with the hook. Later on, there is a vulnerability discovered in the hook which ties into a compromise of an external protocol that offers incentives. The Guard_Admin would have to disable the hook entirely due to the vulnerability though Guard.sol - `updateHookStatus()` and setting the hook `uint8 bitmap` to zero. 

Although this reduces further risks posed by the hook, this will effectively DOS the `stopRent()` flow for any active Rental Orders that uses the hook.

When any of the rental order is due, `stopRent()` can be called to transfer assets, due to the Rental Order is created with the hook, all of the hooks within the rental order needs to be passed through `_removeHooks()`. This means that , the disabled hook will fail the `STORE.hookOnStop(target)` check and directly revert the entire transaction. No assets can be transferred.

```solidity
//src/policies/Stop.sol
    function stopRent(RentalOrder calldata order) external {
...
        if (order.hooks.length > 0) {
            //@audit all the order hooks will be passed to _removeHooks()
|>          _removeHooks(order.hooks, order.items, order.rentalWallet);
        }
    }


    function _removeHooks(
        Hook[] calldata hooks,
        Item[] calldata rentalItems,
        address rentalWallet
    ) internal {
...
        for (uint256 i = 0; i < hooks.length; ++i) {
...
            //@audit this reverts the entire stopRent() flow DOS funds transfer, if a single hook is subsequently disabled for hookOnStop()
            if (!STORE.hookOnStop(target)) {
|>