Create hash index on delete_tasks.index_uid

[guilload]

Description

That query is very slow on Airmail but not at all on Cicada.

@trinity-1686a, what are your thoughts? Should we make (index_uid, opstamp`) the primary key of this table instead? The b-tree could help select both the index UID and max opstamp.

How was this PR tested?

Ran migrations.

[trinity-1686a]

i'm supprised there is a bottleneck there on Airmail. I didn't think delete was used on that cluster.
A primary key/btree index on (index_uid, opstamp) would help with every queries we do.
It looks like we never delete old delete_tasks, so an index covering opstamp will become necessary at a time or another in the life of a cluster. But I think that means we should GC tasks which aren't useful anymore ("all splits up to date, and task older than x minutes", to make sure no new split with an old opstamp is created). With that, a hash on index_uid would probably be enough, as there wouldn't be that many delete tasks in store at any given time, and that number wouldn't grow with time either.