Make app AutoField configurable on first deployment

[browniebroke]

While not fully addressing the problem reported in #307, it switches new installations to use a BigAutoField for primary key. Existing installations won't see any changes unless they replay the migrations and to recreate the result table.

[auvipy]

we should also think about what if existing projects want to migrate to this

[browniebroke]

we should also think about what if existing projects want to migrate to this

Thta's true, but that is more complicated and I don't think I want to tackle migrating existing installations in this pull request.

Such migration might not even be feasible in a database agnostic way, as writing a safe migration might need to use database specific features. The project is tested against Postgres only, but it doesn't seem to use any PG only features? Is it supposed to work on other databases backend supported by Django?

[browniebroke]

There is another setting DJANGO_CELERY_RESULTS_TASK_ID_MAX_LENGTH which should probably be added here but I'd rather do this separately if you don't mind.

[auvipy]

what is your take on this PR? although it is not 100% design wise #314

[browniebroke]

what is your take on this PR? although it is not 100% design wise #314

That could also be a solution to the problem described in #307, although I would argue that's solving an othogonal problem. It's a bit heavy handed for thoses who only want to customise the primary key, and new users usually won't know about the primary key overflow until it's too late.

I'm seeing a fundamental missing piece betwen both PRs: formalising django-celery-results app settings better. What do you think of the implementation in this PR? I took this pattern from this post, which is making a great case for it.

If you have another pattern you prefer, I'm happy to use another example as a blueprint. I can contribute this piece separately first.