Fixes #20290: Avoid exceptions when upgrading to v4.4 from early releases due to missing ObjectTypes table

[jeremystretch]

Fixes: #20290

This PR is submitted as an alternative to #20473.

• Hook into ObjectType.objects.get_for_model() to fall back to using the ContentType manager method in event the ObjectType database table does not yet exist. (This should only ever happen during a migration to v4.4.)
• The has_feature() utility function now support resolving feature support for ContentTypes without querying its corresponding ObjectType in the database.

[jnovinger]

I definitely like this approach much more than my own, which simply bailed out of operations that could poison the transaction, versus providing a fallback like this does. I'm still beating on it a bit, should have an actual review shortly.

[jnovinger]

So, I did find one edge case, although I think it is pretty unlikely. Here are the cases I tested:

• GOOD: v3.7.8 directly to v4.4.0, failed as expected
• GOOD: v3.7.8 to this branch, run full migrations, succeeds as expected
• GOOD: v3.7.8 to v4.3.0 to v4.4.0, running full migrations at each, succeeds as expected
• GOOD: v3.7.8 to v4.4.0, checking out each minor release along the way and running full migrations, succeeds as expected
• BAD: v3.7.8 to v4.4.0, migrations fail as expected, check out this branch, specifically only run users migrations (specific STR below)

STR

1. Check out v3.7.8, restore demo data, run all migrations
2. Check out v4.4.0, run all migrations, see expected failure
3. Check out the branch for this PR and run ./manage.py migrate users in order to test the fix with the offending migration from the original issue.

Expected

All users migrations run successfully.

Actual

Same ProgrammingError raised, but from another location:

Traceback (most recent call last):
  File "/Users/jnovinger/development/netbox-community/netbox/netbox/./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)

  ...  

  File "/Users/jnovinger/.virtualenvs/netbox-312/lib/python3.12/site-packages/django/core/management/commands/migrate.py", line 380, in handle
    emit_post_migrate_signal(
  File "/Users/jnovinger/.virtualenvs/netbox-312/lib/python3.12/site-packages/django/core/management/sql.py", line 52, in emit_post_migrate_signal
    models.signals.post_migrate.send(
  File "/Users/jnovinger/.virtualenvs/netbox-312/lib/python3.12/site-packages/django/dispatch/dispatcher.py", line 189, in send
    response = receiver(signal=self, sender=sender, **named)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jnovinger/development/netbox-community/netbox/netbox/core/signals.py", line 63, in update_object_types
    ot = ObjectType.objects.get_by_natural_key(app_label=app_label, model=model_name)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jnovinger/development/netbox-community/netbox/netbox/core/models/object_types.py", line 47, in get_by_natural_key
    return self.get(app_label=app_label, model=model)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  
  ...

  File "/Users/jnovinger/.virtualenvs/netbox-312/lib/python3.12/site-packages/django/db/backends/utils.py", line 105, in _execute
    return self.cursor.execute(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jnovinger/.virtualenvs/netbox-312/lib/python3.12/site-packages/psycopg/cursor.py", line 97, in execute
    raise ex.with_traceback(None)
django.db.utils.ProgrammingError: relation "core_objecttype" does not exist
LINE 1: ...type"."public", "core_objecttype"."features" FROM "core_obje...

[jeremystretch]

Thanks for the thorough testing. Looks like we should make the change to get_by_natural_key() that we made for get_for_model().

[jeremystretch]

After making the above-mentioned change, I'm getting further errors which I think are from the search backend. It might be reasonable to just flag this scenario as an outlier and ship this as-is. In the off-chance it presents issues in real-world deployments we can revisit.

[jeremystretch]

AFAICT the remaining issue that @jnovinger flagged may be due to a missing dependency declaration, but I haven't been able to narrow it down. Given that it's such an outlier, we've decided to flag it as a known issue for now and proceed with merging this PR. The fix as implemented should resolve all common upgrade paths.