## What's up with the shady patch functions?
Django currently does not provide a way to extend certain classes that are used when auto-generating migrations using `makemigrations`. The patch functions use Python's standard mocking framework to direct certain functions to a custom implementation.

These patches allow `django-postgres-extra` to let Django auto-generate migrations for `PostgresPartitionedModel`, `PostgresViewModel` and `PostgresMaterializedView`.

None of the patches fundamentally change how Django work. They let Django do most of the work and only customize for Postgres specific models. All of the patches call the original implementation and then patch the results instead of copying the entire implementation.

### Using the patches
The patches are all context managers. The top level `postgres_patched_migrations` context manager applies all patches for the duration of the context.

This is used in the custom `pgmakemigrations` command to extend the migration autodetector for `PostgresPartitionedModel`, `PostgresViewModel` and `PostgresMaterializedView`.

### Patches
#### Autodetector patch
* Patches `django.db.migrations.autodetector.MigrationAutodetector.add_operation`

This function is called every time the autodetector adds a new operation. For example, if Django detects a new model, `add_operation` is called with a new `CreateModel` operation instance.

The patch hooks into the `add_operation` function to transform the following operations:

* `Createmodel` into a `PostgresCreatePartitionedModel` operation if the model is a `PostgresPartitionedModel` and adds a `PostgresAddDefaultPartition` operation to create a default partition.

* `DeleteModel` into a `PostgresDeletePartitionedModel` operation if the model is a `PostgresPartitionedModel`.

* `CreateModel` into a `PostgresCreateViewModel` operation if the model is a `PostgresViewModel`.

* `DeleteModel` into a `PostgresDeleteviewModel` operation if the model is a `PostgresViewModel`.

* `CreateModel` into a `PostgresCreateMaterializedViewModel` operation if the model is a `PostgresMaterializedViewModel`.

* `DeleteModel` into a `PostgresDeleteMaterializedViewModel` operation if the model is a `PostgresMaterializedViewModel`.

* `AddField` into `ApplyState` migration if the model is a `PostgresViewModel` or `PostgresMaterializedViewModel`.

* `AlterField` into `ApplyState` migration if the model is a `PostgresViewModel` or `PostgresMaterializedViewModel`.

* `RenameField` into `ApplyState` migration if the model is a `PostgresViewModel` or `PostgresMaterializedViewModel`.

* `RemoveField` into `ApplyState` migration if the model is a `PostgresViewModel` or `PostgresMaterializedViewModel`.

#### ProjectState patch
* Patches `django.db.migrations.state.ProjectState.from_apps`

This function is called to build up the current migration state from all the installed apps. For each model, a `ModelState` is created.

The patch hooks into the `from_apps` function to transform the following:

* Create `PostgresPartitionedModelState` from the model if the model is a `PostgresPartitionedModel`.
* Create `PostgresViewModelState` from the model if the model is a `PostgresViewModel`.
* Create `PostgresMaterializedViewModelState` from the model if the model is a `PostgresMaterializedViewModel`.

These custom model states are needed to track partitioning and view options (`PartitioningMeta` and `ViewMeta`) in migrations. Without this, the partitioning and view optiosn would not end up in migrations.