[fastx client & benchmark] Updated client wrapper to use objects. Updated readme commands

[oxade]

What
Balances are still used in parts of the code.
Why
Part of broader move to object model
This has to be removed as a precursor to benchmarking work since scripts and benchmarking scripts are using old logic.
Limitations
Client wrapper used to accept explicit balances, but now randomly generates ObjectIDs for use. Will enhance in future to use custom IDs or IDs from actual objects/resources
Transfer issue found: #105

[sblackshear]

TOML fixes look good--thanks for that!

My remaining question is still #91 (comment) think we should decide on that and make sure this PR is moving us toward our goal.

How do you see CreateAccounts being used going forward? I could imagine, e.g.,

create_accounts 10 (creates 10 gas currency objects with some default value)
create_accounts 10 --value 150 (creates 10 gas currency objects with value 50)
create_accounts 10 20 30 (creates 3 gas currency objects with value 10, 20, 30)

[sblackshear]

It seems like the commands do a mix of printing output and writing it to a file. We should probably pick one output mechanism and stick to it?

[oxade]

It seems like the commands do a mix of printing output and writing it to a file. We should probably pick one output mechanism and stick to it?

@sblackshear yes. I largely stuck with them to maintain parity with the commands from the ReadMe examples which are doing some basic bash parsing on the outputs.
But it makes sense to overhaul this and only print for commands that execute get queries.

[sblackshear]

After studying at the client code a bit more, I don't think swapping out the "output to a file" logic for printing is moving in the right direction. The design of the existing client (as far as I can tell) is that you do queries to sync the latest state to a file, then use that file for subsequent operations (e.g., preparing txes to send). If we take away the file, we'll need to add a new mechanism for doing this later.

I like the changes this PR is making to CreateAccounts, but I think it should save the results to a file in the same style as the existing command.

[oxade]

After studying at the client code a bit more, I don't think swapping out the "output to a file" logic for printing is moving in the right direction. The design of the existing client (as far as I can tell) is that you do queries to sync the latest state to a file, then use that file for subsequent operations (e.g., preparing txes to send). If we take away the file, we'll need to add a new mechanism for doing this later.

I like the changes this PR is making to CreateAccounts, but I think it should save the results to a file in the same style as the existing command.

Ah you're talking about QueryObjects?
Yes will address that to sync to file

[sblackshear]

• Yes, my bad, I meant QueryObjects instead of CreateAccounts (specifically, the deletion at 449)
• I'm agnostic on printing in addition to saving to a file. If the goal of this PR is to update the existing wrapper API's to use objects, maybe stick to that + file a task for adding printing to all commands (not just the ones being updated by this command)? It's worth noting that the more Rust-idiomatic way to do this sort of printing would be to have each command return a structured object that implements Display + allow the client to toggle printing on and/off with (e.g.) a -q flag, so perhaps worth hashing that out in a separate PR.

[oxade]

• Yes, my bad, I meant QueryObjects instead of CreateAccounts (specifically, the deletion at 449)

Agreed. Will address this.

• I'm agnostic on printing in addition to saving to a file. If the goal of this PR is to update the existing wrapper API's to use objects, maybe stick to that + file a task for adding printing to all commands (not just the ones being updated by this command)? It's worth noting that the more Rust-idiomatic way to do this sort of printing would be to have each command return a structured object that implements Display + allow the client to toggle printing on and/off with (e.g.) a -q flag, so perhaps worth hashing that out in a separate PR.

Will rather do it properly in the Rust-style. Will open a task for this: #104