SFrxETHAdapter redemptionQueue waiting period can DOS adapter functions
The waiting period between `rebalancer` address making a withdrawal request and the withdrawn funds being ready to claim from `FraxEtherRedemptionQueue` is extremely long which can lead to a significant period of time where some of the protocol's functions are either unusable or work in a diminished capacity.\\nIn FraxEtherRedemptionQueue.sol; the Queue wait time is stored in the state struct `redemptionQueueState` as `redemptionQueueState.queueLengthSecs` and is curently set to `1_296_000 Seconds` or 15 Days; as recently as January however it was at `1_555_200 Seconds` or `18 Days`. View current setting by calling `redemptionQueueState()` here.\\n`BaseLSTAdapter::requestWithdrawal()` is an essential function which helps to maintain `bufferEth` at a defined, healthy level. `bufferEth` is a facility which smooth running of redemptions and deposits.\\nFor redemptions; it allows users to redeem `underlying` without having to wait for any period of time. However, redemption amounts requested which are less than `bufferEth` will be rejected as can be seen below in `BaseLSTAdapter::prefundedRedeem()`. Further, there is nothing preventing `redemptions` from bringing `bufferEth` all the way to `0`.\\n```\\n    function prefundedRedeem(address recipient) external virtual returns (uint256, uint256) {\\n        // SOME CODE\\n\\n        // If the buffer is insufficient, shares cannot be redeemed immediately\\n        // Need to wait for the withdrawal to be completed and the buffer to be refilled.\\n>     if (assets > bufferEthCache) revert InsufficientBuffer();\\n\\n        // SOME CODE\\n    }\\n```\\n\\nFor deposits; where `bufferEth` is too low, it keeps user `deposits` in the contract until a deposit is made which brings `bufferEth` above it's target, at which point it stakes. During this time, the `deposits`, which are kept in the adapter, do not earn any yield; making those funds unprofitable.\\n```\\n    function prefundedDeposit() external nonReentrant returns (uint256, uint256) {\\n    // SOME CODE\\n>     if (targetBufferEth >= availableEth + queueEthCache) {\\n>         bufferEth = availableEth.toUint128();\\n            return (assets, shares);\\n        }\\n    // SOME CODE\\n    }\\n```\\n
Consider adding a function allowing the rebalancer call `earlyBurnRedemptionTicketNft()` in `FraxEtherRedemptionQueue.sol` when there is a necessity. This will allow an immediate withdrawal for a fee of 0.5%; see function here
If the `SFrxETHAdapter` experiences a large net redemption, bringing `bufferEth` significantly below `targetBufferEth`, the rebalancer can be required to make a withdrawal request in order to replenish the buffer. However, this will be an ineffective action given the current, 15 Day waiting period. During the waiting period if `redemptions > deposits`, the `bufferEth` can be brought down to `0` which will mean a complete DOSing of the `prefundedRedeem()` function.\\nDuring the wait period too; if `redemptions >= deposits`, no new funds will be staked in `FRAX` so yields for users will decrease and may in turn lead to more redemptions.\\nThese conditions could also necessitate the immediate calling again of `requestWithdrawal()`, given that withdrawal requests can only bring `bufferEth` up to it's target level and not beyond and during the wait period there could be further redemptions.
```\\n    function prefundedRedeem(address recipient) external virtual returns (uint256, uint256) {\\n        // SOME CODE\\n\\n        // If the buffer is insufficient, shares cannot be redeemed immediately\\n        // Need to wait for the withdrawal to be completed and the buffer to be refilled.\\n>     if (assets > bufferEthCache) revert InsufficientBuffer();\\n\\n        // SOME CODE\\n    }\\n```\\n