Unnecessary index drop/recreate when renaming a column

[sparrowt]

Hi again and thank you for your work on this!

I believe 6048db2 has introduced some unnecessary index drop/recreate pairs, when renaming a column, for indexes which that column does not participate in.

E.g. now in this part of _alter_field we have:

        # Have they renamed the column?
        if old_field.column != new_field.column:
            sql_restore_index = ''
            # Drop unique indexes for table to be altered
            index_names = self._db_table_constraint_names(model._meta.db_table, index=True)
            for index_name in index_names:
                # ... _db_table_delete_constraint_sql(...)

which seems to drop all uniq indexes discovered by self._db_table_constraint_names(model._meta.db_table, index=True) for the table, regardless of whether they include old_field.column.

They are correctly recreated AFAICS, so the database should end up in the correct state at the end ✔

However for large tables the time taken to drop & recreate indexes could mean that migrations now unnecessarily take far longer than they used to⚠

Is there a reason all indexes for the table are dropped, rather than only those which involve the column to be renamed?

(I'm not sure how to add a regression test for this, given the end state is correct - unless we start using unittest.mock or logging capture to inspect what statements are run, while executing a migration directly from a TransactionTestCase?)

[absci]

Thanks for the suggestion, I'll do more optimizations for this in the future.

[sparrowt]

Proposed fix here: #97