Vulnerability: A user can lose funds in `sdlPoolSecondary` if tries to add more sdl tokens to a lock that has been queued to be completely withdrawn
Severity: medium

Description:
In a secondary chain, if a user adds more sdl amount into a lock that he has queued to withdraw all the amount in the same index batch, he will lose the extra amount he deposited\\nThe process to withdraw all the funds from a lock in a primary chain is just by calling withdraw with all the base amount of the lock. At this point the user will get immediately his funds back and the lock will be deleted, hence the owner will be zero address.\\nHowever, in a secondary chain, a user has to queue a withdraw of all the funds and wait for the keeper to send the update to the primary chain to execute the updates and then receive his sdl token back. In this period of time when the keeper does not send the update to the primary chain, if a user queues a withdraw of all the lock base amount, he will still own the lock because the withdraw has not been executed, just queued. So the user can still do whatever modification in his lock, for example, increase his lock base amount by calling `transferAndCall()` in the `sdlToken` passing the address of the `sdlSecondaryPool` as argument.\\nIf this happens, when the keeper send the update to the primary chain and the user executes the updates for his lockId, he will lose this extra amount he deposited because it will execute the updates in order, and it will start with the withdraw of all the funds, will delete the ownership (make the zero address as the owner), and then increase the base amount of the lock that now owns the zero address.\\nAnd basically the lockId will be owned by the zero address with base amount as the extra sdl tokens that the user sent.\\nIt is written inside `sdl-pool-secondary.test.ts` because it uses its setup\\n```\\n  it('PoC user will lose extra deposited tokens', async () => {\\n\\n    let user = accounts[1]\\n    let initialUserSDLBalance = await sdlToken.balanceOf(user);\\n\\n    // User creates a lock depositing some amount\\n    await sdlToken\\n      .connect(signers[1])\\n      .transferAndCall(\\n        sdlPool.address,\\n        toEther(100),\\n        ethers.utils.defaultAbiCoder.encode(['uint256', 'uint64'], [0, 0])\\n      )\\n\\n    await sdlPool.handleOutgoingUpdate()\\n    await sdlPool.handleIncomingUpdate(1)\\n    await sdlPool.connect(signers[1]).executeQueuedOperations([])\\n\\n    assert.equal(await sdlPool.ownerOf(1), user)\\n    \\n    // User queues a withdraw of all the amount from the lock\\n    await sdlPool.connect(signers[1]).withdraw(1, toEther(100))\\n\\n    // User wants to deposit more tokens to the lock without the withdraw being updated and still being in the queue\\n    await sdlToken\\n      .connect(signers[1])\\n      .transferAndCall(\\n        sdlPool.address,\\n        toEther(1000),\\n        ethers.utils.defaultAbiCoder.encode(['uint256', 'uint64'], [1, 0])\\n      )\\n\\n    await sdlPool.handleOutgoingUpdate()\\n    await sdlPool.handleIncomingUpdate(2)\\n    // When executing the updates, zero address will be the owner of his lock\\n    // and the amount he diposited the last time will be lost\\n    await sdlPool.connect(signers[1]).executeQueuedOperations([1])\\n\\n    let finalUserSDLBalance = await sdlToken.balanceOf(user);\\n    let sdlLost = initialUserSDLBalance.sub(finalUserSDLBalance)\\n\\n    console.log("The user has lost", sdlLost.toString(), "sdl tokens")\\n\\n    // This staticall should revert because now the lock owner is the zero address\\n    await expect(sdlPool.ownerOf(1)).to.be.revertedWith('InvalidLockId()')\\n  })\\n```\\n\\nOutput:\\n```\\n  SDLPoolSecondary\\nThe user has lost 1000000000000000000000 sdl tokens\\n    ✔ PoC user is not able to execute his lock updates (159ms)\\n\\n\\n  1 passing (3s)\\n```\\n

Impact:
High, user will lose funds

Recommended mitigation:
When trying to do any action on a lock in a secondary pool, check if the last update queued has not 0 as the base amount. Because if it is the case, that would mean that the user queued a withdraw of all funds and he will lose ownership of the lock at the next keeper update.\\n```\\n     function _queueLockUpdate(\\n         address _owner,\\n         uint256 _lockId,\\n         uint256 _amount,\\n         uint64 _lockingDuration\\n     ) internal onlyLockOwner(_lockId, _owner) {\\n         Lock memory lock = _getQueuedLockState(_lockId);\\n// Add the line below\\n        if(lock.amount == 0) revert();\\n         LockUpdate memory lockUpdate = LockUpdate(updateBatchIndex, _updateLock(lock, _amount, _lockingDuration));\\n         queuedLockUpdates[_lockId].push(lockUpdate);\\n         queuedRESDLSupplyChange // Add the line below\\n=\\n             int256(lockUpdate.lock.amount // Add the line below\\n lockUpdate.lock.boostAmount) -\\n             int256(lock.amount // Add the line below\\n lock.boostAmount);\\n         if (updateNeeded == 0) updateNeeded = 1;\\n\\n         emit QueueUpdateLock(_owner, _lockId, lockUpdate.lock.amount, lockUpdate.lock.boostAmount, lockUpdate.lock.duration);\\n     }\\n```\\n