How to reproduce the problem:

1) Create an ODT file which has an OLE object, where the native data i
an OLE2 container, containing a Package stream, containing a DOCX file.

2) Install some external application on Windows which registers itself
as a handler for the DOCX CSLID [ this is where writing a testcase for
this bug is challenging ].

3) Load the ODT file in hidden mode, e.g. connect to a

 ./soffice "--accept=socket,host=localhost,port=9999;urp;StarOffice.ServiceManager"

process from remote Java, load the file with Hidden=true in the
Arguments parameter of loadComponentFromURL().

4) Save it in a format that reads the replacement graphic of OLE
objects, like HTML or DOC.

Expected result: the replacement graphic is there.

Actual result: the <img> tag has no src attribute (HTML case).

The root cause is that in case the document is loaded in hidden mode
then the IDataObject::GetData() call in OleComponent::getTransferData()
fails, so the OLE objects enters a state where it no longer has its old
replacement graphic, but it doesn't have a new one, either.

Fix the problem by making this update more transactional in
svt::EmbeddedObjectRef::GetReplacement(), so the "document conversion"
scenario (load in one format in hidden frame, save in other format)
works.

Change-Id: I624c372baea56a85fb949bd99046f3af1f258c36
Reviewed-on: https://gerrit.libreoffice.org/62549Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins