[fastx dist.sys] Augment fastnft to deal with many input and output objects per transactions

[gdanezis]

This handles the issue #8 . It involves:

• Augmenting the 'Order' struct with 'input_objects' returning object refs.
• Modifying the 'handle_order' to check and lock multiple objects.
• Add an 'execute' to 'Order' that takes input objects and returns output objects.
• Modify the 'handle_confirmation_order' to handle many input / outputs.

Out of scope:

• Currently the handlers return an 'AccountInfoResponse' which is not quite right for multi-object orders, but we will have to see what the client API wants instead, rather than guessing now (related to client issue [fastx distsys] Adapt fastpay client into fastnft client handling objects #7 ).

[huitseeker]

So here you're correctly avoiding any shadowing issue by not putting signed_order.order in your pattern, great!
But you could also do, perhaps more simply, if lock == Some(signed_order.order)

[gdanezis]

Hm, but I need to do something different in all three cases:

• Some(lock) == lock

• Some(lock) =/= lock

• None

        if let Some(existing_signed_order) = lock {
            if existing_signed_order.order == signed_order.order {
                // For some reason we are re-inserting the same order. Not optimal but correct.
                continue;
            } else {
                // We are trying to set the lock to a different order, this is unsafe.
                return Err(FastPayError::OrderLockReset);
            }
        }
  

So if I do the equality test instead of the let binding, then I will have to add a subsequent if to test if it is none, not equal, and then return the Err, right? Is there a better pattern?

[huitseeker]

yeah sorry I read too fast. This may be useful, but it's equivalent to what you have;
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b09a069e4a42cb50528ca5c871d73967

[gdanezis]

Quick comments to attract @patrickkuo attention to returns.

[gdanezis]

@patrickkuo I am now at the point when I am thinking what the 'handle_order' and 'handle_confirmation_order' should return, since now many objects could be changed / created / deleted by an order. Since you are looking at the client, what are your thoughts on what you need? We would have to make the authority return this.

[patrickkuo]

Since I don't have a complete list of client operation at the moment so I will suggest we leave it for now?

The ops I knew we need on objects so far are:
Create, Transfer, Split, Combine, and Delete (and Clone?), I will create an issue to discuss this.

[gdanezis]

Lets make an issue to discuss all this, and leave this question out of this PR -- thanks!

[patrickkuo]

one small comment, otherwise LGTM

[patrickkuo]

is _c intentional?

[gdanezis]

Good catch, changed it to 'c'