Partitioned models with existing `AutoField` primary keys cause issues in 3.0.0 release candidate

[dashdanw]

We are experimenting with upgrading using the 3.0.0-rc1 release candidate in order to upgrade our main repo to Django==5.2 and have encountered issues with existing partitioned models with AutoFields.

If a model in our database has already declared a standard/default AutoField (which implies primary_key=True) the field is dynamically redeclared as primary_key=False in an attempt to also declare a CompositePrimaryKey (see this line).

We would ideally like a way to continue using the standard id/pk AutoFIeld or a happy path to convert the existing AutoField into some type of auto increment unique non-primary key.

Steps to replicate

1. Declare a partitioned model in Django~=4.2.0 using django_postgres_extra~=2.0.9 or earlier including at least one partitioning key

from psqlextra.models.partitioned import PostgresPartitionedModel
class MyModel(PostgresPartitionedModel):
     # inside our app.py AppConfig our DEFAULT_AUTO_FIELD is used e.g `django.db.models.AutoField`
     # this also occurs when declaring
     # id = models.AutoField()
     timestamp = ...
     class MyModelMeta:
        method = PostgresPartitioningMethod.RANGE
        key = ["timestamp"]

2. Run migrations/initialze app
3. Upgrade Django==5.2 and django-postgres-extra==3.0.0-rc1
4. Try to create migrations, observe

$ : python manage.py check       
SystemCheckError: System check identified some issues:

ERRORS:
auditlog.LogEntry.id: (fields.E100) AutoFields must set primary_key=True.
indigo.UserAction.id: (fields.E100) AutoFields must set primary_key=True.

System check identified 2 issues (0 silenced).