[Protocol3] Added circuit testing support + small improvements

[Brechtpd]

• The circuits testing executable is made with make. All tests can be run with npm run test-circuits.
• The rounding error check is now done on the rate of the actual trade (fillS/fillB) instead of on the rounding error on the division to calculate fillB. This should be more accurate and is cheaper.
• When cancelling an order with an orderID > tradingHistory.orderID the filled amount is reset to 0. This accurately represent the filled amount of the orderID stored in the trading history (but the order is cancelled, so it doesn't actually matter for the protocol).

[dong77]

When cancelling an order with an orderID > tradingHistory.orderID the filled amount is reset to 0. This accurately represent the filled amount of the orderID stored in the trading history (but the order is cancelled, so it doesn't actually matter for the protocol).

Let's assume one particular slot will be used by ID 1, 101, 201, .... 901... When we set the slot's current ID to 801 with some non-zero filed amount, does that guarantee that all orders (created or not) that have id=1, 101,...701 are considered canceled (fully matched)?

It is also my understanding that the filled amount set shall never be 0, otherwise, it will clear all history data for order 1, 101, ... 701.

[Brechtpd]

When cancelling an order with an orderID > tradingHistory.orderID the filled amount is reset to 0. This accurately represent the filled amount of the orderID stored in the trading history (but the order is cancelled, so it doesn't actually matter for the protocol).

Let's assume one particular slot will be used by ID 1, 101, 201, .... 901... When we set the slot's current ID to 801 with some non-zero filed amount, does that guarantee that all orders (created or not) that have id=1, 101,...701 are considered canceled (fully matched)?

It is also my understanding that the filled amount set shall never be 0, otherwise, it will clear all history data for order 1, 101, ... 701.

There are 2^TREE_DEPTH_TRADING_HISTORY trading history leafs which store [filled, canceled, orderID]. The slot used by the order is orderID % 2^TREE_DEPTH_TRADING_HISTORY. So only orders with the same orderID after the modulo are affected by a trade history update for a specific slot (so 2^TREE_DEPTH_TRADING_HISTORY slots can be used independently from each other).

So let's say an order gets partially filled with filled := 100 for orderID := 2. The user creates another order with orderID := 2 + 2^TREE_DEPTH_TRADING_HISTORY. This order will use the same slot, but because new orderID > tradeHistory.orderIDit will override the current filled amount, so it will be as filled := 0. The order with orderID := 2 is now considered cancelled because orderID < tradeHistory.orderID and the filled amount is trimmed from the Merkle tree.

What was changed in this PR is that cancellations of orders only updated the canceled value in the leaf. So if orderID := 2 was filled for 100, but you cancel an order with orderID := 2 + 2^TREE_DEPTH_TRADING_HISTORYthe leaf would contain [100, true, 2 + 2^TREE_DEPTH_TRADING_HISTORY], which is not accurate because the order with the orderID that is now stored in the leaf was never filled. But this is just to be consistent, this doesn't matter for the protocol because canceled is true and the orderID is updated, so all orders with orderID <= orderID := 2 + 2 ^TREE_DEPTH_TRADING_HISTORY are canceled. The filled amount stored in the leaf will not be used any more by the protocol because the slot can now only be used by orders with orderID >= 2 + n * 2^TREE_DEPTH_TRADING_HISTORY with n >= 2, which will override the filled amount in the leaf.

[dong77]

When cancelling an order with an orderID > tradingHistory.orderID the filled amount is reset to 0. This accurately represent the filled amount of the orderID stored in the trading history (but the order is cancelled, so it doesn't actually matter for the protocol).

Let's assume one particular slot will be used by ID 1, 101, 201, .... 901... When we set the slot's current ID to 801 with some non-zero filed amount, does that guarantee that all orders (created or not) that have id=1, 101,...701 are considered canceled (fully matched)?
It is also my understanding that the filled amount set shall never be 0, otherwise, it will clear all history data for order 1, 101, ... 701.

There are 2^TREE_DEPTH_TRADING_HISTORY trading history leafs which store [filled, canceled, orderID]. The slot used by the order is orderID % 2^TREE_DEPTH_TRADING_HISTORY. So only orders with the same orderID after the modulo are affected by a trade history update for a specific slot (so 2^TREE_DEPTH_TRADING_HISTORY slots can be used independently from each other).

So let's say an order gets partially filled with filled := 100 for orderID := 2. The user creates another order with orderID := 2 + 2^TREE_DEPTH_TRADING_HISTORY. This order will use the same slot, but because new orderID > tradeHistory.orderIDit will override the current filled amount, so it will be as filled := 0. The order with orderID := 2 is now considered cancelled because orderID < tradeHistory.orderID and the filled amount is trimmed from the Merkle tree.

What was changed in this PR is that cancellations of orders only updated the canceled value in the leaf. So if orderID := 2 was filled for 100, but you cancel an order with orderID := 2 + 2^TREE_DEPTH_TRADING_HISTORYthe leaf would contain [100, true, 2 + 2^TREE_DEPTH_TRADING_HISTORY], which is not accurate because the order with the orderID that is now stored in the leaf was never filled. But this is just to be consistent, this doesn't matter for the protocol because canceled is true and the orderID is updated, so all orders with orderID <= orderID := 2 + 2 ^TREE_DEPTH_TRADING_HISTORY are canceled. The filled amount stored in the leaf will not be used any more by the protocol because the slot can now only be used by orders with orderID >= 2 + n * 2^TREE_DEPTH_TRADING_HISTORY with n >= 2, which will override the filled amount in the leaf.

This is something @hosschao and @lydy should take a look at.