Feat/message broadcaster without simulation

[aarmoa]

• Added logic to allow the transaction broadcaster to calculate gas limit without simulating the transaction

[achilleas-kal]

The example as is fails with an out of gas error as per this tx.

It looks like DEFAULT_GAS_LIMIT is not being added and we send the tx simply with DEFAULT_EXCHANGE_GAS_LIMIT (100k). We should not calculate gas per "message" but per "object". Clients send a single message i.e. MsgBatchUpdateOrders but that includes multiple order placements and cancellations.

I also strongly recommend we have more in-depth gas calculation for exchange objects. Order placement with order cancellation have a lot of difference in terms of gas and MMs already pay a lot in gas daily, they'd need to have a more curated calculation instead of paying 100K gas for every exchange interaction.

[achilleas-kal]

Effectively the calculation should include:

1. Default_gas_limit = gas for the tx itself since fields such as memo and timeout_height cost gas.
2. Gas per object
3. You can consider a "buffer" variable than can also be modifiable be the clients so we can have more strict gas per object and have a buffer to account for different ops in IAVL.

[achilleas-kal]

Thank you @aarmoa.

1. Could we allow AVERAGE_CANCEL_ALL_AFFECTED_ORDERS to be modifiable by clients separately for spot and derivative orders? I think users should ideally be able to set the number of spot and derivative orders to cancel separately and then we calculate gas based on the constants we have. We could also consider adding a buffer here that can be also overridden by clients to account for transient orders.
2. There's no need to have support for MsgBatchCancel, MsgBatchCreate on spot/derivatives. We should only have support for MsgBatchUpdateOrders in the future. This message allows them to perform any action on the exchange. The chain team is also making improvements only on this specific message (i.e. error flags on the chain show only for MsgBatchUpdateOrders). We can also remove the examples in the SDK and also API docs. Effectively these are obsolete messages upon introducing MsgBatchUpdateOrders.

[aarmoa]

@achilleas-kal let me see what I can do for point 1.
Regarding point 2, since those messages are still present in the SDK and I have already implemented the code to estimate their gas cost, I don't see the need to remove them now. We can remove them when the messages are no longer present in the SDK.