Tests which show database integrity corruptions

[adamretter]

Two test suites for database corruption, one for XML documents and one for Binary documents. Both test suites run the same tests but for the respective document type.

Currently there are:

• 4 failing test cases for Binary documents.
• 6 failing test cases for XML documents.

Each test case is executed on a clean instance of the database to ensure there are no "knock-on" effects from one test case to another.

Perhaps the most revealing of the test cases is AbstractRecoveryTest#storeAndLoad().

I have previously fixed and can provide a PR for the binary issues!
Unfortunately the XML corruptions are much more serious, and difficult to understand, as they appear to be between eXist-db's BTree's and the Journal recovery.

I previously raised the issue of these corruptions in July 2017, but they have received little attention. I am opening this issue to make the tests more accessible and to increase visibility.

[dizzzz]

impressive

[wolfgangmm]

There seems to be a bug in the test: looking at AbstractRecoverTest.storeAndLoad, it deletes the temporary data dir via existEmbeddedServer.restart(), so recovery doesn't find a transaction log to recover from.

To see the real issue I have to disable temporary storage. Would be nicer to run it with temporary data dir though.

[adamretter]

@wolfgangmm Right you are. I fixed that and just rebased. Still failures, but less of them now.

[wolfgangmm]

After two days of debugging I managed to fix the first of the underlying issues, bringing the number of failing XML recovery tests down to 4. The remaining failures are likely related. The issue is caused by a long comment in conf.xml whose value needs to be stored into an overflow page as it exceeds 4k. The link to this overflow page got lost as the recovery log did not record the information.

[dizzzz]

@wolfgangmm Nice catch wolf!

[duncdrum]

needs a rebase

[dizzzz]

Needs to be rebased

[adamretter]

Closed/Superseded by #2241