XWIKI-22613: Updating the history can take a very long time when there are a lot of objects

[tmortagne]

Jira URL

https://jira.xwiki.org/browse/XWIKI-22613: Updating the history can take a very long time when there are a lot of objects
https://jira.xwiki.org/browse/XWIKI-22752: Allows indicating in the Hibernate hbm configuration files that an entity should be compressed
https://jira.xwiki.org/browse/XWIKI-22747: Introduce the concept of XWiki Hibernate adapter

Changes

Description

The main goal of this change is to stop storing diff in the document history table.

The "stop storing diff" part is easy, but it implies trying to optimize the RCS table to try to reduce its size as much as possible by compressing it. Since the way to do this is not handled by Hibernate and quite different depending on the database engine, I also used this opportunity to improve how we deal with the difference between database engine with a new HibernateAdapater concept.

Clarifications

See the following for more details and discussion around each subject:

• stop storing diff in the document history: https://forum.xwiki.org/t/stop-storing-diffs-by-default-in-the-history/15886
• new HibernateAdapter API: https://forum.xwiki.org/t/new-xwiki-api-to-extend-the-hibernate-dialects/16193

Executed Tests

• XWikiDocumentArchiveTest now contains several unit tests checking both the new (always full patch) and old behavior (full every 5 versions)

TODO:
The main goal of this pull request is improving document save performances, which is not something which is easy to accurately test in an integration test.
But it could still be interesting to add tests for the following:

• do the tables have the expected right row format in MySQL/MariaDB ?
• do the tables have the right COMPRESS status in Oracle ?

Expected merging strategy

• Prefers squash: Yes
• Backport on branches: none (too dangerous, at worst everything this change is automating can be done by hand in older versions)