Vulnerability: When `queueNewRewards` is called, caller could transfer tokens more than it should be
Severity: high

Description:
Inside `queueNewRewards`, irrespective of whether we're near the start or the end of a reward period, if the accrued rewards are too large relative to the new rewards (queuedRatio is greater than newRewardRatio), the new rewards will be added to the queue (queuedRewards) rather than being immediately distributed.\\n```\\n    function queueNewRewards(uint256 newRewards) external onlyWhitelisted {\\n        uint256 startingQueuedRewards = queuedRewards;\\n        uint256 startingNewRewards = newRewards;\\n\\n        newRewards += startingQueuedRewards;\\n\\n        if (block.number >= periodInBlockFinish) {\\n            notifyRewardAmount(newRewards);\\n            queuedRewards = 0;\\n        } else {\\n            uint256 elapsedBlock = block.number - (periodInBlockFinish - durationInBlock);\\n            uint256 currentAtNow = rewardRate * elapsedBlock;\\n            uint256 queuedRatio = currentAtNow * 1000 / newRewards;\\n\\n            if (queuedRatio < newRewardRatio) {\\n                notifyRewardAmount(newRewards);\\n                queuedRewards = 0;\\n            } else {\\n                queuedRewards = newRewards;\\n            }\\n        }\\n\\n        emit QueuedRewardsUpdated(startingQueuedRewards, startingNewRewards, queuedRewards);\\n\\n        // Transfer the new rewards from the caller to this contract.\\n        IERC20(rewardToken).safeTransferFrom(msg.sender, address(this), newRewards);\\n    }\\n```\\n\\nHowever, when this function tried to pull funds from sender via `safeTransferFrom`, it used `newRewards` amount, which already added by `startingQueuedRewards`. If previously `queuedRewards` already have value, the processed amount will be wrong.

Impact:
There are two possible issue here :\\nIf previously `queuedRewards` is not 0, and the caller don't have enough funds or approval, the call will revert due to this logic error.\\nIf previously `queuedRewards` is not 0, and the caller have enough funds and approval, the caller funds will be pulled more than it should (reward param + `queuedRewards` )

Recommended mitigation:
Update the transfer to use `startingNewRewards` instead of `newRewards` :\\n```\\n    function queueNewRewards(uint256 newRewards) external onlyWhitelisted {\\n        uint256 startingQueuedRewards = queuedRewards;\\n        uint256 startingNewRewards = newRewards;\\n\\n        newRewards // Add the line below\\n= startingQueuedRewards;\\n\\n        if (block.number >= periodInBlockFinish) {\\n            notifyRewardAmount(newRewards);\\n            queuedRewards = 0;\\n        } else {\\n            uint256 elapsedBlock = block.number // Remove the line below\\n (periodInBlockFinish // Remove the line below\\n durationInBlock);\\n            uint256 currentAtNow = rewardRate * elapsedBlock;\\n            uint256 queuedRatio = currentAtNow * 1000 / newRewards;\\n\\n            if (queuedRatio < newRewardRatio) {\\n                notifyRewardAmount(newRewards);\\n                queuedRewards = 0;\\n            } else {\\n                queuedRewards = newRewards;\\n            }\\n        }\\n\\n        emit QueuedRewardsUpdated(startingQueuedRewards, startingNewRewards, queuedRewards);\\n\\n        // Transfer the new rewards from the caller to this contract.\\n// Remove the line below\\n        IERC20(rewardToken).safeTransferFrom(msg.sender, address(this), newRewards);\\n// Add the line below\\n        IERC20(rewardToken).safeTransferFrom(msg.sender, address(this), startingNewRewards);\\n    }\\n```\\n