Acceptance tests for token allowance amounts

[jascks]

Description:
With the implementation of #3576 completed, implement acceptance tests around the new functionality provided, namely crypto and token allowance definition and that approved crypto/fungible token transfers are properly reflected in the allowance balances.

• Create fungible token and allowance defining appropriate owner and spender IDs.
• Verify existence and expected configuration via mirror node rest api
• Perform fungible token transfer, both approved utilizing the owner and spender as expected, as well as other scenarios that should not affect the allowance balances.
• Refer to code recently added to clean up and recover HBARs spent

Related issue(s):

Fixes #6553

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: +0.12% 🎉

Comparison is base (e90ec06) 92.57% compared to head (364695f) 92.70%.
Report is 2 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6592      +/-   ##
============================================
+ Coverage     92.57%   92.70%   +0.12%     
+ Complexity     6503     6392     -111     
============================================
  Files           841      823      -18     
  Lines         27348    27079     -269     
  Branches       3126     3104      -22     
============================================
- Hits          25318    25104     -214     
+ Misses         1319     1270      -49     
+ Partials        711      705       -6     

see 20 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[xin-hedera]

LGTM

[steven-sheehy]

LGTM

[steven-sheehy]

This doesn't actually ensure that the transaction has been seen by mirror node, just consensus nodes, right? Does it need to to avoid race conditions?

[jascks]

Oooh... Yes, this is only an interaction with the consensus nodes (HAPI). My comment is a lie! While that did appear to solve the issue, it could become problematic again.

When using the named token mechanism (TokenClient.getToken()) the token may or may not be created. So there may or may not be a transaction. Instead, in this step, after calling getToken() the mirror node API should be invoked to ensure the token exists (/api/v1/tokens?token.id=<tokenId>) with the standard retry template retrying 404.

Does that make sense? I can create a new ticket and PR to address this.

[steven-sheehy]

Can just ensure the transaction is present on mirror node

[jascks]

Created issue #6648, opened PR #6649.