Transaction Isolation Levels überarbeiten

Why

Im Zustelldienst wird an sehr vielen Stellen @Transactional(isolation = Isolation.REPEATABLE_READ) verwendet. Die historischen Gründe dafür waren:

1. Jede direkte oder transitive Verwendung von Attachment und ReplyAttachment (DB: oid => Entity: byte[]) hat dies nötig gemacht, weil sonst der Fehler "Large Objects may not be used in auto-commit mode." auftrat. Nach dem Merge von #1574 (closed) ist dieses aber nicht mehr nötig.
2. Teilweise hat ineffizienter, 2-stufiger Pagination-Code eine gewisse Berechtigung dafür dargestellt, das Ergebnis konsistent zu halten. Dieser Code wurde aber schon mit #1590 (closed) abgelöst.
3. Sicherlich sind manche Stellen schlichtweg durch copy-paste entstanden.

Die Probleme sind:

1. Noise im Code
2. Aufgrund des aggressiveren Lockings in der DB erleiden wir Performance-Einbußen
3. Es werden LockAcquisitionExceptions mit "ERROR: could not serialize access due to concurrent update" provoziert (wie in den Logs von TEST zu erkennen).

Siehe auch:

• https://en.wikipedia.org/wiki/Isolation_(database_systems)
• https://stackoverflow.com/questions/50797097/postgres-could-not-serialize-access-due-to-concurrent-update

Acceptance criteria

1. Alle @Transactional-Annotationen wurden auf Sinnhaftigkeit überprüft
2. Wo immer es möglich ist, wird @Transactional (ohne Argumente) verwendet, was READ_COMMITTED entspricht. Dies kann ggf. sogar auf Klassen-Level geschehen, wenn für alle Methoden der Klasse dieselbe Logik gelten soll.

Implementation plan (to be completed by the developer)

• Definition of Done was checked.