update psycopg to v3.1.12

[jeriox]

closes #949

[coveralls]

coverage: 84.399% (+0.005%) from 84.394%
when pulling f3a885e on psycopg3
into 11434ec on 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. ...