Fix/approval change

[zcstarr]

No description provided.

[jriemann]

Overall, these changes look pretty good. I think it makes sense to have the two new functions as you have them.
One thing we might want to change is the owner_id name, since we use the same name in other contexts in the spec (like in the Token type, where it is used to indicate singular ownership of a token). Perhaps approval_creator_id? or something else?

Adding to what's here, I think we need to update the mt_transfer* methods as well. As it stands, we only take approval_id (a number) as an argument. I think it should take a tuple of (approval_id, owner_id).

Rationale: the most natural structure to keep track of approvals is by using 3 nested maps, basically
token_id -> owner_id -> grantee_id -> (approval_id, amount). This makes the creation & deletion operations very simple to reason about.
However, when calling transfer, if the contract isn't provided with the owner_id, it will need to iterate over keys, testing various owner_id values until it finds a match for the given approval_id. I think this will be pretty messy & inefficient.

And also, mt_resolve_transfer needs to take an argument of all the approvals to be restored in case of failure. Since we have batch transfers wherein each transfer can clear multiple approvals, I think the argument should be (deep breath): approvals: (null | (amount: string, approval_id: number, owner_id: string)[])[] | null .

Thoughts?

[zcstarr]

approvals

I think these adjustments make sense pushing up some changes in a few

[zcstarr]

@jriemann PTAL we let me know what you think.

[jriemann]

LGTM. Thanks for making the changes.