Fix migration that drops unique index

[adamiak]

Resolves L2B-1051

Rolling back this migration would cause a uniqe index to be re-added but we can't do it since there is potentially already data in DB that has correct duplicates (adding unique index was a mistake in the first place). This PR changes the migration so that id never re-adds the unique index, just keeps the one without unique contraint.

[linear]

L2B-1051 Fix migration 032_drop_uniqueness_from_preprocessed

There was a unique index that had to be dropped (due to Perpetuals on Gammax supporting use case where a single user has multiple positions).

Migration 32 drops the unique key, but it turns out that when this migration is rolled back (I'm not sure exactly when, Mateusz had this happen when starting backend with FRESH_START), it tries to re-add the unique index (see down()), which fails because there are obviously violations in the table.

Don't be tempted to use a simple solution of just not moving back to unique index. If you do that, then migrating again to 32 will fail, because it tries to drop a unique index that wouldn't exist.

I guess the only solution here is to delete * from the table when rolling back. Consult with piotr.szlachciak if this is a good idea.