A concurrent call to getXDOM can replace the prepared content of a document with its unprepared content

XWikiDocument#getXDOM() stores the XDOM it parses in the cached content without checking whether another thread prepared the content in the meantime. When a thread calls getXDOM() on a document whose content isn't parsed yet while another thread finishes getPreparedXDOM(), the parsed but unprepared XDOM can overwrite the prepared one, while the preparation date stays set.

getPreparedXDOM() then returns the unprepared XDOM as prepared until the content of the document changes. Rendering still works since macros are executed on unprepared blocks too, but the document loses the benefit of the cached preparation (e.g. the syntax highlighting of the code macro is computed again for each rendering).

A possible fix is to keep the XDOM and its preparation date together in a single immutable value held in an AtomicReference, and to let getXDOM() store its result only with compareAndSet(null, ...). This also removes the need to read the preparation date before the XDOM.

Found while reviewing XWIKI-25414, which doesn't change this behavior.