Update client API to support new cost fields in dryrun result

[algoidurovic]

Depends on: algorand/go-algorand#3957

[jasonpaulos]

Looks good to me, but I expect the blackbox testing code that @tzaffi has added also needs to be updated because of this change. It seems to reference cost in many places.

[tzaffi]

Perhaps cost is a synonym to budget-debit? In that case I would ask that cost be kept as an additional redundant field (which keeps the same behavior as currently), but that an issue be created in this repo to mark cost as deprecated. When this issue is created, I'll create an issues in the graviton and pyteal repos to stop using cost and which block the issue in this repo.

If I'm wrong in my assumption, then I'll need to understand a bit better the relationship between cost and the new fields.

[algoidurovic]

Perhaps cost is a synonym to budget-debit? In that case I would ask that cost be kept as an additional redundant field (which keeps the same behavior as currently), but that an issue be created in this repo to mark cost as deprecated. When this issue is created, I'll create an issues in the graviton and pyteal repos to stop using cost and which block the issue in this repo.

If I'm wrong in my assumption, then I'll need to understand a bit better the relationship between cost and the new fields.

Close, but budget-credit is more similar to the old cost field, although you can't rely on the values being equal. I can bring back the old field as it was (with the strange underflow behavior) or make it exactly equal to budget-credit. The distinction is only relevant when the app being tested has inner app calls that increase budget.

[tzaffi]

Perhaps cost is a synonym to budget-debit? In that case I would ask that cost be kept as an additional redundant field (which keeps the same behavior as currently), but that an issue be created in this repo to mark cost as deprecated. When this issue is created, I'll create an issues in the graviton and pyteal repos to stop using cost and which block the issue in this repo.
If I'm wrong in my assumption, then I'll need to understand a bit better the relationship between cost and the new fields.

Close, but budget-credit is more similar to the old cost field, although you can't rely on the values being equal. I can bring back the old field as it was (with the strange underflow behavior) or make it exactly equal to budget-credit. The distinction is only relevant when the app being tested has inner app calls that increase budget.

Is the cost the same as budget-credit for apps that don't have inner transactions, and in this case, there is no "underflow" issue?

If that's the case, I think there's no need to try and re-create the strange and buggy underflow behavior. This isn't something I was using, and requiring community members to rewrite tests that relied on this wrong value is not too much to ask, in my opinion.

In short, assuming that budget-credit is the same as cost for simple apps with no inner transactions, then I advocate making cost a synonym of budget-credit. But then this leaves me wondering if the budget-credit field is even necessary or can be renamed cost.

[tzaffi]

As the repo has no existing tests that validate cost in dry-run, I think it's ok to accept as is. @barnjamin may want to have a look as well.