[CENT-361] Modify TokenTestUtils function buildExpectedState/getActualState

[mirathewhite]

Updated TokenTestUtils to use the Accounts interface for managing token state

• Create empty state object fiatTokenEmptyState using all Accounts
• Use fiatTokenEmptyState in buildExpectedState
• getActualState uses compact lambda expressions

Removed some redundant code from other files.

[mirathewhite]

Unit test run was taking about 1 hour. I removed some accounts from Accounts. I also created a subset of Accounts (allowanceMappingAccounts) for evaluating the allowances map. This decreased the typical unit test time from 6500ms to 2700ms.
-- Some unit tests changed to use different accounts
-- getAccountState now queries a mapping in parallel
-- Removed duplicate accounts
-- Removed some await statements that were causing sequential execution
-- Modified spreadsheets to avoid code/description discrepancies
-- Verifier correctly identifies unit tests suites (contracts) that are not in any spreadsheet

[walkerq]

I have some concerns with this approach:

• Testing only a subset of account allowances is faster, but we can't be sure that other allowances are not being modified, so we might as well defensively test all combinations of our known account allowances. Even if the current tests only modify a subset of account allowances, future tests might modify allowances outside of that subset.
• We should keep the definitions of the expected state objects defined statically. That way, it is easy to verify that we are checking all the defaults we want to check. Building up the object's structure dynamically saves lines of code, but adds risk that we are not setting defaults correctly.

What do you think @o-a-hudson?

[o-a-hudson]

I have some concerns with this approach:

• Testing only a subset of account allowances is faster, but we can't be sure that other allowances are not being modified, so we might as well defensively test all combinations of our known account allowances. Even if the current tests only modify a subset of account allowances, future tests might modify allowances outside of that subset.
• We should keep the definitions of the expected state objects defined statically. That way, it is easy to verify that we are checking all the defaults we want to check. Building up the object's structure dynamically saves lines of code, but adds risk that we are not setting defaults correctly.

What do you think @o-a-hudson?

I agree with @walkerq 's suggestions here. I think that will make the testing less error-prone which seems worth it given that this is smart contract code. I think we could consider other approaches for speeding up the tests, such as parallelizing the tests across different blockchain network instances each with a subset of the tests.

[walkerq]

typo: mappingQuery -> accountQuery

[mirathewhite]

fixed

[walkerq]

comment can be deleted

[mirathewhite]

fixed

[walkerq]

We don't want to commit this file, do we?

[mirathewhite]

ooops - this is a personal scratch file.

[walkerq]

We might want to move this to AccountUtils

[mirathewhite]

fixed.