Try dropping foreign keys before indexes and add performance timing for it.

The basic issue being looked at here is that we are taking a long time to drop a non-existent foreign key from a table. The issue can be seen as follows: 1) start hivemind in massive sync and let it run for 20M blocks, stop it, then restart it so that it tries to drop some foreign keys.

This whole problem seemed quite strange, so I started looking into it to see what the problem was. At first I assumed there was some lock on the table prevent us from dropping it (but that was wrong and in retrospect probably never made since because the foreign key doesn't exist since it was dropped during step 1).

Changing the order didn't solve anything (but it seemed logical to drop the keys before the indexes, so I made the change anyways "for-the-future"), but I also added some logging to show the problem (takes about 10 minutes on an extremely fast system).

Further investigation of this issue seems to suggest the problem is related to shadow tables. I tried executing the same drop query that was hanging during massive sync, and I got warnings about not having privileges to write to shadow tables (which after talking to Bartek probably should not even exist at that time). This problem will be assigned to someone for further investigation.

P.S. Someone should also check that this problem doesn't happen right away from starting hivemind in massive sync without even stopping it first.