THE USER WHO WITHDRAWS LIQUIDITY FROM A PARTICULAR POOL IS ABLE TO CLAIM MORE REWARDS THAN HE DULY DESERVES BY CAREFULLY SELECTING A `decreaseShareAmount` VALUE SUCH THAT THE `virtualRewardsToRemove` IS ROUNDED DOWN TO ZERO
Audit: 2024-01-salty-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-01-salty/blob/main/src/staking/StakingRewards.sol#L113-L118
https://github.com/code-423n4/2024-01-salty/blob/main/src/staking/StakingRewards.sol#L132-L133
https://github.com/code-423n4/2024-01-salty/blob/main/src/staking/StakingRewards.sol#L99


# Vulnerability details

## Impact

The `StakingRewards._decreaseUserShare` function is used to decrease a user's share for the pool and have any pending rewards sent to them. When the amount of pending rewards are calculated, initially the `virtualRewardsToRemove` are calculated as follows:

		uint256 virtualRewardsToRemove = (user.virtualRewards * decreaseShareAmount) / user.userShare;

Then the `virtualRewardsToRemove` is substracted from the `rewardsForAmount` value to calculate the `claimableRewards` amount as shown below:

		if ( virtualRewardsToRemove < rewardsForAmount )
			claimableRewards = rewardsForAmount - virtualRewardsToRemove; 

But the issue here is that the `virtualRewardsToRemove` calculation is rounded down in favor of the user and not in the favor of the protocol. Since the `virtualRewardsToRemove` is rounded down there is an opportunity to the user to call the `StakingRewards._decreaseUserShare` function with a very small `decreaseShareAmount` value such that the `virtualRewardsToRemove` will be rounded down to `0`. Providing a very small `decreaseShareAmount` value is possible since only input validation on `decreaseShareAmount` is `! = 0` as shown below:

		require( decreaseShareAmount != 0, "Cannot decrease zero share" );

When the `claimableRewards` is calculated it will be equal to the `rewardsForAmount` value since the `virtualRewardsToRemove` will be `0`. This way the user can keep on removing his liquidity from a particular pool by withdrawing small `decreaseShareAmount` at a time such that keeping `virtualRewardsToRemove` at `0` due to rounding down. 

Furthermore the `decreaseShareAmount` value should be selected in such a way `rewardsForAmount` is calculated to a considerable amount after round down (not zero) and the `virtualRewardsToRemove` should round down to zero.

Hence as a result the `user` can withdraw all the `rewardsForAmount` as the `claimableRewards` even though some of those rewards are `virtual rewards` which should not be claimable as clearly stated by the following `natspec` comment:

		// Some of the rewardsForAmount are actually virtualRewards and can't be claimed.

Hence as a result the user is able to get an undue advantage and claim more rewards for his liquidity during liquidity withdrawable. This happens because the `user` can bypass the `virtual reward` subtraction by making it round down to `0`. As a result the `virtualReward` amount of the `rewardsForAmount`, which should not be claimable is also claimed by the user unfairly.

## Proof of Concept

```solidity
		// Determine the share of the rewards for the amountToDecrease (will include previously added virtual rewards)
		uint256 rewardsForAmoun