Add index for cancellation timestamp

[MartinquaXD]

Description

Simply fetching the recently updated/added orders for updating the solvable orders cache is surprisingly slow. On mainnet this takes anywhere between 250ms and 3s (resolution of the time buckets is not ideal).
This query basically has the shape SELECT fields FROM orders WHERE cancellation_timestamp > $1 OR creation_timestamp > $1 OR uid = ANY($2). When running the query with EXPLAIN ANALYZE it became apparent that creation_timestamp > $1 is very fast but cancellation_timestamp > $1 is not. It turned out there was only 1 index using cancellation_timestamp and it was in an index btree(creation_timestamp, cancellation_timestamp). This query can only be used to search orders by creation_timestamp very efficiently but not by cancellation_timestamp.

When I added an index btree(cancellation_timestamp) the query time dropped from ~150ms to ~2ms. It's not completely clear how this translates to the prod environment since my test DB ran the originally query significantly faster than the prod replica but a speed up of 75x will certainly not hurt.

Changes

• removed unused index
• added useful one
• updated DB readme with new and previously missing indexex

How to test

manual tests on a cloned prod db

[github-actions]

Reminder: Please update the DB Readme and comment whether migrations are reversible (include rollback scripts if applicable).

• If creating new tables, update the tables list.
• When adding a new index, consider using CREATE INDEX CONCURRENTLY for tables involved in the critical execution path.
• For breaking changes, remember that during rollout k8s starts the new autopilot, runs the Flyway migration, and only then shuts down the old pod. That overlap means the previous version can still be processing requests on the migrated schema, so make it compatible first and ship the breaking DB change in the following release.

---

Caused by:

• database/sql/V095__update_order_timestamp_indexes.sql

[squadgazzz]

LGTM. If we still encounter issues with this query, we should probably start looking into restructuring the orders table.