update psycopg to v3

[jeriox]

closes #949

[coveralls]

coverage: 81.25% (-0.1%) from 81.356% — psycopg3 into main

[felixrindt]

blocked by django-tenants/django-tenants#959

[jeriox]

blocked by django-tenants/django-tenants#959

this is merged and released in 3.6 of django-tenants

[felixrindt]

might be this: https://forum.djangoproject.com/t/connection-lock-hanging-after-upgrading-psycopg/30826/5

[felixrindt]

@dependabot rebase

[felixrindt]

We found out that Cursors in pscopg3 use a threading.Lock on the Connection object to execute queries. Inside the lock, field values are serialized. What happens in the ModelLogging module is

• we try to save a logged object
• in the post_save signal, saving of a LogEntry is triggered
• LogEntry is saved, and only inside a block protected by the lock, the JSON field contents are serialized
• our custom JSONserializer executes a query to get a contenttype
• that query uses the same connection object, which is locked by the LogEntry save, and thus we get a deadlock

We don't know why the value serialization happens inside the connection lock yet. Seams like this is before any DB interaction, but maybe it's needed for psycopgs implementation to be threadsafe. Thus, we need to move the serialization outside the lock (before we call save) or avoid queries (with that locked connection) inside our serialization method.

This could be done using

1. The already committed monkey patch/workaround, which serializes json content before the the query is executed.
2. A custom json field that does that.
3. ...

[felixrindt]

hmm crazy we have to go through the str type here instead of just serializing the fields inside the dict/list structure