When creating resources within an 'init' stage, can break txNumber test

[nklincoln]

If you create a series of assets within the init phase of a benchmark callback, the the txCount is incremented since deep in the code a callback that increments the txCount is called.

If you are relying on a test that runs for a certain number of transactions, then all of these transactions will count for the test transactions ... this is bad and we should avoid it.

Context

Running a benchmark with a txNumber specification resulted in no test transactions being issued.

Expected Behavior

All txNumber transactions are run

Actual Behavior

Any transactions run in the init phase count towards test transactions

Possible Fix

Add a boolean flag (testPhase, default false?) to the invokeSmartContract that is passed though and acted on conditionally when triggering the callback that increments the txCount

[nklincoln]

There is an existing countQueryAsLoad option that is used in query operations - proposal is to do similar with a countTransactionAsLoad option (or indeed make a generic countAsLoad) so that the way to perform a "loaded txn" is the same for users

[aklenik]

@nklincoln How about using az init round for populating the backend DLT? It's much cleaner, and you get every feature the rounds can use.
(Although ignoring the round in the report could be useful in this case.)

[nklincoln]

fixed in #682