Remove protocol gas limits

[anajuliabit]

Fix #668

[coveralls]

coverage: 99.693% (-0.01%) from 99.704% when pulling 11bfb4d on remove-gas-limits into f14d952 on main.

[zajck]

A few things:

1. We should keep maxTwinsPerBundle. Length of _bundle.twinIds is not problematic during in createBundleInternal, but later in transferTwins. Transfer twins should limit the gas it passes to twin contract when making a transfer #687 will add a max gas that a single twin transfer can consume, but if there is a large number of twins, they could collectively still reach the block gas limit and effectively DoS redeemVoucher. If we keep maxTwinsPerBundle we can ensure that maxTwinsPerBundle * maxGasPerTwinTransfer will always be low enough that redeemVoucher will succeed.
2. burnPremintedVouchers(uint256 _offerId) must also accept uint256 _amount, so the seller can regulate how many vouchers are burned. Currently end = range.start + range.minted; can be so high that the gas limit is reached. It should be end = range.start + amount; instead.
3. [just a remark, nothing to do]. createTwinInternal can run into a block gas limit since the following value can be arbitrarily high.
   

   boson-protocol-contracts/contracts/protocol/bases/TwinBase.sol

   Lines 78 to 81 in 939e256

   	uint256 twinRangesLength = twinRanges.length;
   	// Checks if token range isn't being used in any other twin of seller
   	for (uint256 i = 0; i < twinRangesLength; i++) {

   
   The problem is alleviated with Fix twin inefficiencies  #656 but we cannot say it won't exist anymore. In theory, a seller could have so many twins, that creating a new twin won't be possible anymore (around 11,500 at current gas limits). We could introduce maxActiveTwins, so if the seller reached it, they could not create a new twin until they remove some of the existing ones. But that check would be part of createTwinInternal again, so the overall behaviour is the same:
   • Without check (as it is now) they run into a block gas limit when creating a twin. If they remove a few of them, they can again create new ones.
   • With a check in place they would get a revert reason instead when creating a twin. But then they would still need to remove a few of them to be able to create new ones.
4. getAvailableFunds can run into a gas block limit if tokenList gets too long.
   

   boson-protocol-contracts/contracts/protocol/facets/FundsHandlerFacet.sol

   Lines 166 to 171 in 939e256

   	availableFunds = new Funds[](tokenList.length);
   	// Get entity's availableFunds storage pointer
   	mapping(address => uint256) storage entityFunds = lookups.availableFunds[_entityId];
   	for (uint256 i = 0; i < tokenList.length; i++) {

   
   We need a separate issue to fix it. Probably accepting a _tokenList would do.
5. [just a remark, nothing to do]. removeTwins can run into a block gas limit since the following value can be arbitrarily high.
   

   boson-protocol-contracts/contracts/protocol/facets/TwinHandlerFacet.sol

   Lines 85 to 86 in 939e256

   	uint256 lastIndex = twinRanges.length - 1;
   	for (uint256 index = 0; index <= lastIndex; index++) {

   
   This is fixed in Fix twin inefficiencies  #656
6. I agree that scripts to estimate limits are not necessary anymore. But they still might be valuable to get a feeling of how much the protocol can handle. Maybe you can remove them for now, but at some point, they can be refreshed and the docs rearrange to not talk about the limits (as protocol values) but rather just about protocol capabilities.

[zajck]

LGTM 👍

[mischat]

LGTM