NFT Signatures - remallnfts vs. search performance

Solution 1. Vector table

similar architecture to addaddress
remallnfts works as spec'd
- Vector can be emptied in single call without iterating through all the objects. This allows for remallnfts to work flawlessly

Limit on number of NFTs that can be mapped
- Requires limit on number of NFTs that can be mapped to any single FIO Address due to vector search linear compute time on checking existing entries and checking for items to remove. Like addpubaddress vector but more limited since it iterates with a larger object
Requires update to support get_nfts_hash
- Can’t do it unless all the data is duplicated in another table mapped by sha256 (fioaddress+chaincode+contractaddress+tokenid => hash)
- If mapped, we would need an admin cleanup task these cannot be deleted with all vector entries w/ remallnfts, back to square one.

Cannot remove all nfts.
- Can do 5 at a time, newest to oldest or vice versa
- By making remallnfts have less custom error responses and removing some other checks I may be able to salvage enough cpu time to clean out more NFTs in a single call
Cannot remove NFTs for a FIOAddress in xferaddress or burnexpired.
- For xferaddress, users would need to empty their NFTs using multiple calls to remallnfts first before they can transfer.
- For burnexpired, we would need to iterate through the burning of NFTS for every FIO Address that is getting burned
  - Burnexpired could skip fioaddresses that have NFTs mapped and come back to those at the end if we wanted to optimize burn.

Recommend solution 1 and get_nfts_hash endpoint removed and get_nfts_contract used alternatively