Add Boolean if "subasset" has a fee schedule associated

[Ashe-Oro]

Concern: NFT subassets (otherwise referred to as serial numbered assets) do not indicate if they have been assigned a fee schedule.

Background: In an attempt to identify how accounts can best manage NFTs within the current 1000 NFT limit, subassets can be created to greatly increase the available assets held. It was identified that each sub-asset (ie 0.0.xxx.1 or 0.0.xxx.2) inherit the fee schedule of it's parent, but mirror nodes do not report this data.

Solution: Include a Boolean value on each subasset to indicate if a fee schedule is associated. If TRUE, the user will know to then query the top-level asset to review the fee schedule. This prevents redundant information from being included in the subasset query, while offering a performant and simple solution to review the subasset's inherited fee schedule.

Examples:
Top level asset: https://testnet.mirrornode.hedera.com/api/v1/tokens/0.0.19159052/
Sub asset: https://testnet.mirrornode.hedera.com/api/v1/tokens/0.0.19159052/nfts/1

[steven-sheehy]

A custom fee schedule is directly associated with a token type and not its individual sub-assets. When you query HAPI for a token type via TokenGetInfoQuery it returns the custom fees in its response. But if you query for an individual NFT via TokenGetNftInfoQuery it does not display any custom fees.

Likewise for the mirror node, it makes sense to mirror (pardon the pun) this behavior for consistency. You would query /api/v1/tokens/:id to get the token type's custom fees. As this data rarely if ever changes, you can query this once and cache it for a long period of time. Then you can use this cached data on subsequent calls for individual NFTs at /api/v1/tokens/:id/nfts/:serial.

All NFTs of a token will have the same fee schedule so I don't think there's a need to repeatedly show that information for each NFT. Also, due to the sheer amount of data the mirror node provides we are trying to limit joins between large tables and keep the APIs more encapsulated so they can scale. We think the current separation between token types and token instances strikes that performance and encapsulation balance.