Investigate performance improvements when persisting data [2TB]

[StefanKock]

Problem Description

Follow up to #3481 and #4153: Develop ideas how to decrease the time spent for persisting data that needs to be created very often (usually case, contact or event participant).

Ideas

• [ ] Consider Hibernate 2nd level cache with NONSTRICT_READ_WRITE strategy for entities like Region/District/Community/User/etc

postponed:

1. Extend ReferenceDTO with id and version(changeDate) so that when mapping a relation in the DTO-to-Entity mapping we can just create the minimal detached relation entity that get's attached by Hibernate automatically, and don't fetch all the related entities if nothing is being done with them. (this is a major change in the project that affects a bit also the android app but would improve significantly all the saves)
2. Investigate where we can replace eager with lazy loading
3. Investigate where DTO selections can be reduced to a smaller DTO
4. Consider Hibernate batch insert/update - evaluate if this can be done only for the import part

Deliverable

New tickets that are refined enough to address performance improvements.

[markusmann-vg]

@MartinWahnschaffe to discuss it again with @BarnaBartha

[MartinWahnschaffe]

Resulting tickets have been assigned to the epic #7734

• #10208
• #10214
• #10210 (should not be done now)

and to the epic #7372

• #10293