bug with shared changes and conversion path cached

[prahal]

There is a segfault if a change that is not the first on a member that is not the first and if the memebr have different objformat for the same sink. This in PREPARE_WRITE. Ie the first member to prepare write the change will convert it to its sink format (here vcard21 for my phone). Then the second member (evolution) will try have a cached conversion path (as the change is not the first) of xmlformat-contact to vcard21. Thus when preparing the change that has already been converted by the phone member as vard21 the cached conversion path will tell osync_sink_engine_convert_to_dest to convert what is already vcard21 from xmlformat-contact to vcard21.

This segfault as the xmlformat assembler is not liking the plain vard21 as input.

Attached is a testcase (quite convoluted as it does not detect the issue in the order described above but the opposite . Ie the shared change is first and caching of the conversion path is done on first change which is the shared one. As the second entry_engine is to be written and will use the shared one conversion path (which tells the wrong conversion as corrupted by the previous members) I can detect that the second entry written to file is not in sync with its origin.

[prahal]

testcase

[prahal]

patch for osync_sink_engine_convert_to_dest

[prahal]

tests/data/multisync_multiformats/data1/testdata_to_sync

[prahal]

tests/data/multisync_multiformats/data1/testdata

[prahal]

tests/data/multisync_multiformats/data2/testdata

[prahal]

tests/data/multisync_multiformats/data3/testdata