Replace auction_orders table with index on order_uids column

[MartinquaXD]

Description

When I investigated some of the fallout of the recent DNS issues I noticed that the post-processing that happens in the autopilot run loop (storing important bookkeeping information in the DB before telling the winner to /settle) can be very slow. The biggest offender was the save_auction call that first writes into competition_auctions and then into the auction_orders table. This currently routinely takes 250-500ms according to our metrics.

However, it seems like the write into the auction_orders table is completely redundant as it duplicates the information we already have in competition_auctions::order_uids. The new redundant table was introduced in #4233 to quickly find all auctions that contained a given order uid. However, this can also be achieved using a GIN index on the existing order_uids table.

Changes

Create GIN index on competition_auctions::order_uids and drops auction_orders and updates the remaining references accordingly (db readme, debug skill).

How to test

TODO: take a mainnet snapshot, apply the change there, and verify the GIN index gives reasonable performance

[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/V111__gin_index_orders_in_auction.sql
• database/sql/V112__drop_auction_orders.sql