Follow-ups for buy/sell proto definitions

[clevinson]

Summary

Few followups from #560 that were left as open questions.

Some of these points may be left as is, but we should still make sure to have the conversations here or in WG meetings to align on them before releasing full marketplace functionality into the wild.

• Change UpdateBuyOrders api to be more granular (see comment) Add granular buy/sell update messages #892
• Add support for explicitly cancelling a sell order (see comment)
• update ask_price field to repeated Coin, allowing for a sell order to accept multiple denoms. This may not be a feature we want to enable though, as it creates possibility for strange arbitrage opportunities when exchange rates of "ask denoms" diverge (see comment)
• Rename Sell() & BuyDirect() rpc methods to CreateSellOrders() and (CreateBuyOrders() or DirectBuy())(see comment & here)

Not explicitly brought up in the review, but two additional pieces on my mind:

• re-evaluate params for MsgAllowAskDenom (maybe metadata isn't necessary here if it can be stored in x/bank's DenomMetadata?)
• distinguishing btw BuyDirect and CreateBuyOrder functionality
  • currently, BuyDirect creates a "buy order" that may have some pending state. I'm still not 100% sure of what use case we have for this, and rather think of CreateBuyOrder as a separate API call that would actually create a pending order in state, whereas BuyDirect would always be against an existing open sell order, and be immediately executable

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[aaronc]

Direct buy orders cannot be executed immediately when we have more complex order book matching as they would compete with other open orders and thus need to be subject to the same batching. Thus the logic for introducing order IDs in this iteration. It is a question, however, if we want to persist orders in state that are already complete - likely we don't, but they could still be referenced from events or historical state.

[clevinson]

OK makes sense. @ryanchristo and I started looking into this today...

For now, should the fulfilling of MsgBuyDirect calls be done in batch (e.g. in EndBlocker()?), or should we be directly fulfilling orders as part of the msg server's BuyDirect() call?

[aaronc]

Up to you. Maybe simplest to do it synchronously in the tx

[clevinson]

From ledger product call today:

• Add support for explicitly cancelling a sell order (will add this in existing msg server implementation work from @clevinson and @ryanchristo)
• Let's not persist buy orders to state, but store a ORM seq for buy orders so we can auto increment and dispatch events with buy_order_id