Review if sorting of xmlformat is still needed for the (de)merger

[dgollub]

There used to be problem with some xmlformat entries and the merger. Some entries got passed to the merge unsorted. The merge doesn't validate if the entry is sorted and malformed the entries when merging.

For this reason in several places xmlformat sort calls are instrumented.

Review if this sorting is still required. We should avoid any sorting if possible.

[dgollub]

Implemented in r3589 some debug instrumentation to hunt search() calls on unsorted XMLFormats.

[dgollub]

Immplenet in r3592 another instrumentation to hunt unsorted XMLFormats directly after the merge.

Schedule this ticket for the next milestone to see if there are oustandign issue. If there are no issue till 0.39 - this issue is closed and the bottom line is: No need of sorting of xmlformats within the merger

Setting to prio "highest" - so this one get handled first once 0.38 is out.

[dgollub]

No bugs got reported - no testcase is triggering the error. Reopen if bug reappears.

[deloptes]

I had some issue with this, so I needed to comment it out

/* Searching breaks if the xmlformat is not sorted (bsearch!).

ASSERT in development builds (when NDEBUG is not defined) - see ticket #754. */

osync_assert(xmlformat->sorted); if (!xmlformat->sorted) { osync_error_set(error, OSYNC_ERROR_GENERIC, "XMLFormat is unsorted. Search result would be not valid."); goto error; }