[ECO-624] Fix async dedupe aggregator logic

[alnoki]

#518

• Aggregate both maker and taker side of a fill event
• Update fill aggregation SQL
• Abstract fill/change event total order aggregation sequence

Testing

Updated config.yaml:

health_check_port: 8085
server_config:
  processor_config:
    type: econia_transaction_processor
    econia_address: 0xeeee0dd966cd4fc739f76006591239b32527edbb7c303c431f8c691bda150b40
  postgres_connection_string: postgres://econia:econia@postgres:5432/econia
  indexer_grpc_data_service_address: http://streamer:50051
  indexer_grpc_http2_ping_interval_in_secs: 60
  indexer_grpc_http2_ping_timeout_in_secs: 10
  auth_token: dummy_token
  starting_version: 0

Started local compose:

# From Econia repo root.
docker compose --file src/docker/compose.dss-local.yaml up

Opened:

http://0.0.0.0:3000/limit_orders?order=price.desc,last_increase_stamp.asc&market_id=eq.1&side=eq.ask&order_status=eq.open

Ran trade.py to completion, refreshing the browser after each step:

# In another terminal, also from repo root.
cd src/python/sdk
poetry install
poetry run trade

After script was done, checked http://0.0.0.0:3000/limit_orders?order=price.desc,last_increase_stamp.asc&market_id=eq.1&side=eq.ask&order_status=eq.cancelled:

Using https://chrome.google.com/webstore/detail/json-viewer/gbmdgpbipfallnflgajpaliibnhdgobh/related on Brave

[CRBl69]

Why would you set order status to open ? It seems not very useful since an order cannot be re-opened. It can also introduce errors if cancel and change events are not emitted or processed in error. I think there is no downside to not setting the status to open so why set it to open ?

[alnoki]

Consider:

1. User opens order with remaining size 10
2. User changes remaining size to 15
3. 10 fills

If the events are aggregated out of order, (e.g. event 1, then 3, then 2), the order will be marked closed

[alnoki]

Addressed in 0eb778a