Update load generation logic

[marta-lokhova]

-- Description
* Refactor LoadGenerator to achieve the following:
- Create accounts in a separate step
- Be able to batch up to 100 ops/tx
- Create single payments in a separate step
- Deterministically generate destination account based on the source account and its sequence number
- Mark load generation complete after changes are propagated to the DB
- Update tests to use the new load generator

-- Usage
* A user would hit generateload endpoint with the following params:
- mode [create|pay] - determines accounts creation or payments
- nAccounts - number of accounts to create or use for payments
- nTxs - num payments to perform
- batchsize - when creating accounts, batch multiple ops in a transaction
- txrate - tx/s injestion rate, (num or "auto")
* Note that accounts creations and payments are separate calls to the endpoint

[marta-lokhova]

Note that current version of updateSequenceNumber on master breaks the code (because of usage of REQUIRE), so this change is copied from bump sequence PR.

[vogel]

Is that necessary here?

[marta-lokhova]

It ensures mRoot is set, in case an outside method calls clear before generateLoad.

[vogel]

I think that name and return value of this method are misleading.

This method does not return root account, and its return value is never used.
I propose to either:

• rename it to void LoadGenerator::createRootAccount
• make it return res or nullptr, remove mRoot field and pass returned value to creationTransaction as a parameter

[vogel]

In what case is that true?

[vogel]

Never mind, found that case:)

[vogel]

It looks for me as if there are 2 different methods hiding inside this loop, one for isCreate == true and one for == false. Or maybe it is even small interface with 2 implementation. Following all those if (isCreate) branches one after another is quite hard.

[vogel]

I think it deserves separate method.

[vogel]

I think we could just make std::vector return type and result result.
RVO will take care of copying and having that gives us enough information to get the synced value as well.

[vogel]

it is duplicated in CommandHandler, I think we need to extract that to somewhere

[vogel]

what about displaying message that such values of batchSize are illegal?

[vogel]

looks like name of this function is misleading - mode is not Num

[marta-lokhova]

Thanks for reviewing! Will update the code based on the suggestions.

[vogel]

Looks good to me!
Could you rebase it on current master and squash some commits?

[MonsieurNicolas]

Marking this PR as dependent on #1533 (for the changes in test accounts)

[vogel]

typo - function arguments should start with lower case

[MonsieurNicolas]

r+ 662d653

[marta-lokhova]

@MonsieurNicolas looks like a clang-format issue. Fixed now.

[MonsieurNicolas]

r+ 31a038d

[MonsieurNicolas]

@latobarita: retry