Non-sequential minting (a.k.a spot-minting) support

[Vectorized]

This PR gives ERC721A the ability to mint tokens in non-sequential order.

Devs will need to override a new _sequentialUpTo() function to return a value less than 2**256 - 1 to activate this feature.

About:

• Sequential mint: _startTokenId() <= tokenId <= _sequentialUpTo()
• Spot (i.e. non-sequential) mint: _sequentialUpTo() < tokenId.

Zero-cost abstraction:

• If _sequentialUpTo() == type(uint256).max (by default), all expressions of x > _sequentialUpTo(), x != _sequentialUpTo() will evaluate to false on compile time, and the dead code will be removed. If you don't override _sequentialUpTo(), you won't pay any extra gas.

Notes:

• "Non-sequential" is a mouthful to type. ChatGPT suggests that "spot" is a short word that conveys similar meaning as non-sequential.
• The new storage variable for the total number of spot mints is placed at the end of all the storage variables, so that we can maintain storage compatibility with the current ERC721AUpgradeable.
• Most functionality of ERC721AQueryable can still be used with spot mints. The tokensOfOwner function is disabled if spot mints is enabled, as it would need to scan the entire uint256 range, which is unfeasible. The tokensOfOwnerIn function, however, is still available for use with spot mints, as the search range can be manually restricted. Added some minor optimizations to the scanning logic.

Todo:

• Reason really hard about the code.

[mvillere]

Clever approach to implement this I think. I went through all the changes and didn't see any red flags. The only obvious thing that popped into my head is whether it makes sense to package spot + sequential mint functionality together in a single contract as I don't think a lot of mints will need both together. That being said, I do like having the capability now, and it added a lot less code to the base contract than I expected. Nicely done.

[Vectorized]

@mvillere Thanks so much for your review.

One possible use case is multi-chain NFTs.
L1 minting can be sequential, while NFTs bridged from L2 -> L1 are spot minted.

[cygaar]

The overall approach looks sound to me, however it does seem like this would be better off as an extension rather than be placed in the base ERC721A contract. The usage of this contract seems pretty niche as it's pretty rare to find a contract that needs to mint sequentially and at specific spots

[Vectorized]

Was initially thinking of a subclass that wraps the ERC721A's functions.

Decided on the current approach after hard marinating over a week:

• Ease of use. Just override one function. This logic is intended to be used with burning exposed (via ERC721ABurnable). If we were to make a subclass, we can face Solidity inheritance hell.
• Reuse common logic and storage variables, leading to smaller bytecode and lower runtime gas. Also easier to visually inspect.

[daejunpark]

I focused on reviewing the integrity of _packedOwnerships data structure, and it looked good to me. My observations supporting the integirty are as follows:

• _packedOwnerships is divided into two parts for sequential and spot mintings. While the latter part doesn't hold some sequential properties of the former, they are used differently by identifying which part a given token id belongs to.
• _currentIndex - 1 stays within _sequentialUpTo, ensuring that sequential minting data doesn't spill over into the spot minting area.
• The next slot initialization in transferFrom() and burn() doesn't occur for spot-minted tokens, as their _BITMASK_NEXT_INITIALIZED flag is always set true.

Minor comments are added below.

[dcapitator]

Could we consider implementing batch spot minting as a highly anticipated use case?

Nice work.

[davvviid]

could be less fee for NFTs redeem

[Nlferu]

@Vectorized

I did not want to create new issue for this as I assume answer is clear, but I want to make sure by checking with you.

As you mentioned I use _mintSpot for cross-chain NFT's and I also use batchTransfer, batchBurn etc. but I assume that using _mintSpot disables batchTransfer and batchBurn by following condition: _currentIndex <= tokenId and there is no way to make those work without sequential mint am I right?

To give you some view of my project architecture I use batchMint, batchTransfer and batchBurn (all sequential) for my SourceNFT (blockchain A) and I use _mintSpot for DestinationNFT (blockchain B), so for blockchain B to transfer more tokens It is only possible to just call standard safeTransferFrom for each token right?

There is also one more thing as your docs says _sequentialUpTo() needs to return greater value than _startTokenId(), so I made my sourceNFT _startTokenId = 2 and then on destination my _sequentialUpTo = 1, so user is able to transfer even 1st token. But is it possible to somehow turn on _mintSpot feature from index 0? So we keep minting sequentially from 0 on chain A and then we can use _mintSpot for tokenId = 0? I believe it is not possible to do so...

Thanks in advance for any confirmations/explanation if I'm right or there is a way to solve those problems somehow