Recommendation: Fix weak assertions in MixinStakingPool stemming from use of NIL_POOL_ID
The modifier `onlyStakingPoolOperatorOrMaker(poolId)` is used to authorize actions taken on a given pool. The sender must be either the operator or a confirmed maker of the pool in question. However, the modifier queries `getStakingPoolIdOfMaker(maker)`, which returns `NIL_POOL_ID` if the maker's `MakerPoolJoinStatus` struct is not confirmed. This implicitly makes anyone a maker of the nonexistent “pool 0”:\\n```\\nfunction getStakingPoolIdOfMaker(address makerAddress)\\n    public\\n    view\\n    returns (bytes32)\\n{\\n    IStructs.MakerPoolJoinStatus memory poolJoinStatus = \\_poolJoinedByMakerAddress[makerAddress];\\n    if (poolJoinStatus.confirmed) {\\n        return poolJoinStatus.poolId;\\n    } else {\\n        return NIL\\_POOL\\_ID;\\n    }\\n}\\n```\\n\\n`joinStakingPoolAsMaker(poolId)` makes no existence checks on the provided pool id, and allows makers to become pending makers in nonexistent pools.\\n`addMakerToStakingPool(poolId, maker)` makes no existence checks on the provided pool id, allowing makers to be added to nonexistent pools (as long as the sender is an operator or maker in the pool).
Avoid use of `0x00...00` for `NIL_POOL_ID`. Instead, use `2**256 - 1`.\\nImplement stronger checks for pool existence. Each time a pool id is supplied, it should be checked that the pool id is between 0 and `nextPoolId`.\\n`onlyStakingPoolOperatorOrMaker` should revert if `poolId` == `NIL_POOL_ID` or if `poolId` is not in the valid range: (0, nextPoolId).
```\\nfunction getStakingPoolIdOfMaker(address makerAddress)\\n    public\\n    view\\n    returns (bytes32)\\n{\\n    IStructs.MakerPoolJoinStatus memory poolJoinStatus = \\_poolJoinedByMakerAddress[makerAddress];\\n    if (poolJoinStatus.confirmed) {\\n        return poolJoinStatus.poolId;\\n    } else {\\n        return NIL\\_POOL\\_ID;\\n    }\\n}\\n```\\n