HTS: Add support for token transactions to Importer

[Nana-EC]

Detailed description:
To support the new Token HAPI, we should enhance our importer to import the new token transactions.

• Add a TransactionHandler for each new transaction type
• Add new repository and domain classes for Token, TokenAccount and TokenTransfer
• Update EntityListener and its concrete implementations for the new entities with OnToken(), OnTokenAccount() and OnTokenTransfer()
• Update EntityTypeEnum and EntityId with new TokenID
• Update EntityRecordItemListener to parse the new transaction types and create appropriate domain objects for persistence
• Update TransactionHandlerFactory to return appropriate Token transactionHandler on appropriate transactions type
• Update TransactionTypeEnum with Token transaction types

Which issue(s) this PR fixes:
Fixes #1051

Special notes for your reviewer:

Checklist

• Documentation added
• Tests updated

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@06b6d6a). Click here to learn what that means.
The diff coverage is 89.70%.

@@            Coverage Diff            @@
##             master    #1089   +/-   ##
=========================================
  Coverage          ?   87.71%           
  Complexity        ?      234           
=========================================
  Files             ?      219           
  Lines             ?     5233           
  Branches          ?      575           
=========================================
  Hits              ?     4590           
  Misses            ?      448           
  Partials          ?      195           

Impacted Files	Coverage Δ	Complexity Δ
...va/com/hedera/mirror/importer/domain/EntityId.java	94.87% <ø> (ø)	0.00 <0.00> (?)
...om/hedera/mirror/importer/domain/TokenBalance.java	83.33% <ø> (ø)	0.00 <0.00> (?)
...sactionhandler/TokenCreateTransactionsHandler.java	75.00% <75.00%> (ø)	0.00 <0.00> (?)
...sactionhandler/TokenUpdateTransactionsHandler.java	75.00% <75.00%> (ø)	0.00 <0.00> (?)
.../java/com/hedera/mirror/importer/util/Utility.java	78.68% <77.77%> (ø)	0.00 <0.00> (?)
.../mirror/importer/domain/TokenFreezeStatusEnum.java	83.33% <83.33%> (ø)	0.00 <0.00> (?)
...era/mirror/importer/domain/TokenKycStatusEnum.java	83.33% <83.33%> (ø)	0.00 <0.00> (?)
...m/hedera/mirror/importer/domain/TokenTransfer.java	86.66% <86.66%> (ø)	0.00 <0.00> (?)
...parser/record/entity/EntityRecordItemListener.java	92.19% <87.60%> (ø)	0.00 <0.00> (?)
...om/hedera/mirror/importer/domain/TokenAccount.java	88.23% <88.23%> (ø)	0.00 <0.00> (?)
... and 18 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 06b6d6a...6c61ddd. Read the comment docs.

[steven-sheehy]

Review still in progress, but submitting what I have so you can address.

[steven-sheehy]

These two repository calls will definitely slow things down. I haven't had time to verify if multiple calls to save will be internally batched. This might be fine for now but we'll need to revisit this next sprint.

[Nana-EC]

Agreed. This is best path to get the ball rolling but we definitely need to scale.

Challenge is each update needs to ensure it has the correct information from current state before updating.
e.g. A token gets created with a freeze and Kyc settings to default to FROZEN and REVOKED.
An account then Associates itself with the token, it will be frozen and revoked.
Say accounts it gets Unfrozen and then soon after gets GrantedKyc.
We need to make sure the persistence for the KycGrant picks the fact that it was unfrozen and doesn't accidentally revert the freeze state change.
That's why for now I'm just saving immediately, just like Entity updates do.

Currently using Spring cache so this should give us some breathing room to explore the right solution for Accounts and Tokens

[steven-sheehy]

LGTM