JalaPair potential permanent DoS due to overflow
In the `JalaPair::_update` function, overflow is intentionally desired in the calculations for `timeElapsed` and `priceCumulative`. This is forked from the UniswapV2 source code, and it's meant and known to overflow. UniswapV2 was developed using Solidity 0.6.6, where arithmetic operations overflow and underflow by default. However, Jala utilizes Solidity >=0.8.0, where such operations will automatically revert.\\n```\\nuint32 timeElapsed = blockTimestamp - blockTimestampLast; // overflow is desired\\nif (timeElapsed > 0 && _reserve0 != 0 && _reserve1 != 0) {\\n    // * never overflows, and + overflow is desired\\n    price0CumulativeLast += uint256(UQ112x112.encode(_reserve1).uqdiv(_reserve0)) * timeElapsed;\\n    price1CumulativeLast += uint256(UQ112x112.encode(_reserve0).uqdiv(_reserve1)) * timeElapsed;\\n}\\n```\\n
Use the `unchecked` block to ensure everything overflows as expected
This issue could potentially lead to permanent denial of service for a pool. All the core functionalities such as `mint`, `burn`, or `swap` would be broken. Consequently, all funds would be locked within the contract.\\nI think issue with High impact and a Low probability (merely due to the extended timeframe for the event's occurrence, it's important to note that this event will occur with 100% probability if the protocol exists at that time), should be considered at least as Medium.\\nReferences\\nThere are cases where the same issue is considered High.
```\\nuint32 timeElapsed = blockTimestamp - blockTimestampLast; // overflow is desired\\nif (timeElapsed > 0 && _reserve0 != 0 && _reserve1 != 0) {\\n    // * never overflows, and + overflow is desired\\n    price0CumulativeLast += uint256(UQ112x112.encode(_reserve1).uqdiv(_reserve0)) * timeElapsed;\\n    price1CumulativeLast += uint256(UQ112x112.encode(_reserve0).uqdiv(_reserve1)) * timeElapsed;\\n}\\n```\\n