Squash old migrations

[blms]

I propose:

• delete the tests for the squashed migrations
• IIRC, the old migrations still are preserved in the code once they are squashed; if codecov complains about coverage, we add a codecov config to tell it we don't care about coverage on the old migrations

Originally posted by @rlskoeser in https://github.com/Princeton-CDH/geniza/issues/1485#issuecomment-1779614397

[blms]

@rlskoeser Been working on this today—I'm not sure how feasible it is due to the number of circular dependency errors between the migrations on different apps. As I understand it, because the replaced migrations contained dependencies on the common app, the latest of those (0008_preload_github_coauthors) gets added to the squashed migration as a dependency. However, since a lot of the prior common migrations depended on corpus migrations, they now point towards the squashed migration as a dependency, producing a circular dependency between common and corpus. Moreover, those common migrations also contain dependencies on footnotes migrations, which in turn produces a circular dependency when those footnotes migrations themselves depend on replaced corpus migrations. You can smell the spaghetti cooking here!

I'm seeing a few posts on this django devs group that seem to suggest squashing may be more trouble than it's worth in most cases. They suggest an alternative, essentially doing it manually by resetting all migrations and starting from scratch with makemigrations. Not sure if that makes sense for our needs either.

[rlskoeser]

@blms thanks for looking into this - I remember now the reset and start from scratch scenario, I think we did that on one of our other applications; I would have to look to remind myself which one. I was remembering that with squashing it's tricky to handle the data migrations; had forgotten the problem with the dependencies.

Resetting the migrations sounds like a good solution; you'll still have to preserve the migrations that create data (like groups and coauthors). I glanced at one of the migration reset tutorials linked from your link, which jogged my memory —  we'll just have to fake the new initial migrations when you deploy the update with the reset migration. When we did it before we tracked that in the deploy notes.